angular/integration/cli-hello-world/tsconfig.json

{
  "compileOnSave": false,
  "compilerOptions": {
    "outDir": "./dist/out-tsc",
    "sourceMap": true,
    "esModuleInterop": true,
    "declaration": false,
    "experimentalDecorators": true,
    "module": "es2022",
    "moduleResolution": "bundler",
    "importHelpers": true,
    "target": "es2022",
    "typeRoots": ["node_modules/@types"],
    "lib": ["es2018", "dom"]
  },
  "angularCompilerOptions": {
    "strictTemplates": true
  }
}
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555 2018-01-16 15:09:59 +00:00			`{`
			`"compileOnSave": false,`
			`"compilerOptions": {`
			`"outDir": "./dist/out-tsc",`
			`"sourceMap": true,`
ci: use application builder for integration tests (#55660) This updates the integration tests to use the application builder. PR Close #55660 2024-05-03 17:21:11 +00:00			`"esModuleInterop": true,`
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555 2018-01-16 15:09:59 +00:00			`"declaration": false,`
			`"experimentalDecorators": true,`
build: update ts target to ES2022 and module to ES2022 (#58022) Our integration tests are based on the CLI. CLI build force the target to ES2022 else it logs a warning PR Close #58022 2024-09-30 22:49:03 +00:00			`"module": "es2022",`
build: adopt `moduleResolution: "bundler"` (#64125) This commit updates the TypeScript configuration across the project to use `moduleResolution: "bundler"`. This modernizes our module resolution strategy to align with current TypeScript best practices and bundler behaviors. The following changes are included: - Updated `tsconfig.json` files to set `moduleResolution` to `"bundler"`. - Updated the `rules_angular` bazel dependency to a version compatible with these changes. - Adjusted related test files and golden files to reflect the new module resolution strategy. PR Close #64125 2025-09-29 14:32:10 +00:00			`"moduleResolution": "bundler",`
build: upgrade `cli-hello-world[-ivy]` integration projects to @angular/cli@7.2.1 (#27697) PR Close #27697 2019-01-09 18:53:18 +00:00			`"importHelpers": true,`
build: update ts target to ES2022 and module to ES2022 (#58022) Our integration tests are based on the CLI. CLI build force the target to ES2022 else it logs a warning PR Close #58022 2024-09-30 22:49:03 +00:00			`"target": "es2022",`
test: add integration test for signal inputs in CLI (#53808) This commit introduces a new integration test to ensure signal inputs work as expected for end uses in Angular CLI applications. PR Close #53808 2023-12-07 13:32:37 +00:00			`"typeRoots": ["node_modules/@types"],`
refactor(core): drop the usage of `PromiseSettledResult<void>` (#63955) `PromiseSettledResult<void>` requires the ES2020 typings. Those might not be provided (or `skipLibCheck` is not enabled). fixes #63931 PR Close #63955 2025-09-19 19:30:59 +00:00			`"lib": ["es2018", "dom"]`
feat: make the Ivy compiler the default for ngc (#32219) This commit switches the default value of the enableIvy flag to true. Applications that run ngc will now by default receive an Ivy build! This does not affect the way Bazel builds in the Angular repo work, since those are still switched based on the value of the --define=compile flag. Additionally, projects using @angular/bazel still use View Engine builds by default. Since most of the Angular repo tests are still written against View Engine (particularly because we still publish VE packages to NPM), this switch also requires lots of `enableIvy: false` flags in tsconfigs throughout the repo. Congrats to the team for reaching this milestone! PR Close #32219 2019-08-20 17:52:31 +00:00			`},`
			`"angularCompilerOptions": {`
test: add integration test for signal inputs in CLI (#53808) This commit introduces a new integration test to ensure signal inputs work as expected for end uses in Angular CLI applications. PR Close #53808 2023-12-07 13:32:37 +00:00			`"strictTemplates": true`
test: update integration/cli-hello-world project structure (#33175) PR Close #33175 2019-10-15 13:42:31 +00:00			`}`
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555 2018-01-16 15:09:59 +00:00			`}`