angular/tools/tsconfig.json

{
  "compilerOptions": {
    "strict": true,
    "skipLibCheck": true,
    "declaration": true,
    "esModuleInterop": true,
    "sourceMap": true,
    "module": "NodeNext",
    "moduleResolution": "nodenext",
    "types": ["node"]
  }
}
chore(typescript 1.6 upgrade): fix build.tools 2015-09-22 19:03:39 +00:00			`{`
repackaging: all the repackaging changes squashed 2016-04-29 00:50:03 +00:00			`"compilerOptions": {`
build: migrate symbol-extractor to `ts_project` (#61209) Migrates the symbol-extractor code to `ts_project`. PR Close #61209 2025-05-07 06:50:28 +00:00			`"strict": true,`
			`"skipLibCheck": true,`
repackaging: all the repackaging changes squashed 2016-04-29 00:50:03 +00:00			`"declaration": true,`
build: enable `esModuleInterop` in TypeScript compilations (#43431) Enables the `esModuleInterop` for all TypeScript compilations in the project. This allows us to emit proper ESM-compatible code. e.g. consider the following import: ```ts import * as ts from 'typescript'; ``` This import currently will break at runtime in NodeJS because the `typescript` package is not shipping ESM. It's still a CommonJS module. ES modules are able to import from `typescript` though, using an import statement as above, but everything in `module.exports` is being exposed as the `default` named export. TypeScript at runtime does not have any other named exports, so for actual ESM compatibility, all of our imports need to be switched to: ``` import ts from 'typescript'; ``` The `esModuleInterop` option allows this to work even though the `d.ts` file of TS currently suggests that there are _only_ named exports. The TypeScript language service will now suggest the correct import form as shown above. It doesn't enforce that unfortunately, but this commit also adds a lint rule that enforces certain patterns so that we emit imports that are compatible with both ESM and CJS output (CJS still needed here since tests run with CJS devmode output still; this is a future project to switch that over to ESM!) PR Close #43431 2021-09-25 12:58:32 +00:00			`"esModuleInterop": true,`
repackaging: all the repackaging changes squashed 2016-04-29 00:50:03 +00:00			`"sourceMap": true,`
build: migrate `manual_api_docs` to `rules_js` (#61237) Migrates `manual_api_docs` to `rules_js`. Since compiler CLI is ESM compiled but doesn't have extensions, we can either bundle or simply use the dependency as type only. This is easier and sufficient for this use-case. PR Close #61237 2025-05-07 13:35:29 +00:00			`"module": "NodeNext",`
			`"moduleResolution": "nodenext",`
build: migrate symbol-extractor to `ts_project` (#61209) Migrates the symbol-extractor code to `ts_project`. PR Close #61209 2025-05-07 06:50:28 +00:00			`"types": ["node"]`
build: ts-api-guardian tsconfig warning with bazel (#27583) * Suppresses the warning from the Bazel TypeScript rules about overwritten options from the `tools/tsconfig.json` file. This is the only remaining warning that makes our Bazel build on Angular Material "dirty" PR Close #27583 2018-12-10 19:25:49 +00:00			`}`
			`}`