Files
blockly/tsconfig.json
Christopher Allen d83dcfbe2e chore(build,tests): Remove obsolete kludges / config options (#6835)
* 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.
2023-02-08 11:56:35 +01:00

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": [],
}
}