mirror of
https://github.com/google/blockly.git
synced 2026-01-07 17:10:11 +01:00
* chore(tests): Remove circular import loading issue kludge Prior to PR #6818, circular imports resulted in the debug module loader (in closure/goog/base.js) failing to record the goog.module ID of most modules that were involved in the cycle, and in particular of the Blockly.Xml module. This had secondary fallout that resulted in library blocks modules being loaded in the wrong order. A kludge was introduced in PR #6703 that worked around this problem by making sure that window.Blockly was set, allowing the modules loaded out-of-order to still work. Now that we have removed all remaining circular dependencies there is no need for the kludge, since all module IDs are properly recorded and modules are loaded in the correct order. * chore(build): Remove exclude for non-existent core/blockly.js There was a transitional period where we had both core/blockly.ts and core/blockly.js, and wished to exclude the latter from tsc's input, but the latter file was deleted (and inadvertently restored, then re-deleted) some time ago.
41 lines
1.5 KiB
JSON
41 lines
1.5 KiB
JSON
{
|
|
"include": [
|
|
"core/**/*", // N.B.: also pulls in closure/goog/goog.js if needed.
|
|
"closure/**/*", // Just for ouptut directory structure.
|
|
],
|
|
"compilerOptions": {
|
|
// Tells TypeScript to read JS files, as
|
|
// normally they are ignored as source files
|
|
"allowJs": true,
|
|
|
|
// Generate d.ts files and sourcemaps.
|
|
"declaration": true,
|
|
// Generate declaration maps used for api-extractor
|
|
"declarationMap": true,
|
|
"sourceMap": true,
|
|
|
|
"module": "ES2015",
|
|
"moduleResolution": "node",
|
|
"target": "ES2020",
|
|
"strict": true,
|
|
|
|
// This does not understand enums only used to define other enums, so we
|
|
// cannot leave it enabled.
|
|
// See: https://github.com/microsoft/TypeScript/issues/49974
|
|
// "importsNotUsedAsValues": "error"
|
|
|
|
// tsc has a clever and usually helpful feature ("@types support")
|
|
// wherein it automatically ingests any type definitions found in
|
|
// node_modues/@types/**/*.d.ts. This lets you tell it about the
|
|
// types for your favourite framework or library just by
|
|
// installing the relevant @types/<whatever> npm package.
|
|
//
|
|
// We don't (as of this writing) use this feature, and it causes a
|
|
// problem when one of our dependencies pulls in such a package
|
|
// which turns out to have syntax errors (see e.g. discussion on
|
|
// PR #6564: https://github.com/google/blockly/pull/6564), so
|
|
// disable it except for the explicitly-specified types.
|
|
"types": [],
|
|
}
|
|
}
|