Update blueprint to use @tsconfig/ember

This aligns us with the emerging default across the rest of the
ecosystem and, just as importantly, means that we don't need to have
folks do anything manually to stay in sync as we iterate on and improve
the base config over time: they just need to upgrade the version of the
base config they're using in their `package.json`.

Author: chriskrycho

blueprint-files/ember-cli-typescript/tsconfig.json

@@ -1,65 +1,6 @@
 {
   "compilerOptions": {
-    "target": "ES2021",
-    "module": "ES2020",
-    "moduleResolution": "node",
-
-    // Trying to check Ember apps and addons with `allowJs: true` is a recipe
-    // for many unresolvable type errors, because with *considerable* extra
-    // configuration it ends up including many files which are *not* valid and
-    // cannot be: they *appear* to be resolve-able to TS, but are in fact not in
-    // valid Node-resolvable locations and may not have TS-ready types. This
-    // will likely improve over time
-    "allowJs": false,
-
-    // --- TS for SemVer Types compatibility
-    // Strictness settings -- you should *not* change these: Ember code is not
-    // guaranteed to type check with these set to looser values.
-    "strict": true,
-    "noUncheckedIndexedAccess": true,
-
-    // Interop: these are viral and will require anyone downstream of your
-    // package to *also* set them to true. If you *must* enable them to consume
-    // an upstream package, you should document that for downstream consumers to
-    // be aware of.
-    //
-    // These *are* safe for apps to enable, since they do not *have* downstream
-    // consumers; but leaving them off is still preferred when possible, since
-    // it makes it easier to switch between apps and addons and have the same
-    // rules for what can be imported and how.
-    "allowSyntheticDefaultImports": false,
-    "esModuleInterop": false,
-
-    // --- Lint-style rules
-
-    // TypeScript also supplies some lint-style checks; nearly all of them are
-    // better handled by ESLint with the `@typescript-eslint`. This one is more
-    // like a safety check, though, so we leave it on.
-    "noPropertyAccessFromIndexSignature": true,
-
-    // --- Compilation/integration settings
-    // Setting `noEmitOnError` here allows ember-cli-typescript to catch errors
-    // and inject them into Ember CLI's build error reporting, which provides
-    // nice feedback for when
-    "noEmitOnError": true,
-
-    // We use Babel for emitting runtime code, because it's very important that
-    // we always and only use the same transpiler for non-stable features, in
-    // particular decorators. If you were to change this to `true`, it could
-    // lead to accidentally generating code with `tsc` instead of Babel, and
-    // could thereby result in broken code at runtime.
-    "noEmit": true,
-
-    // Ember makes heavy use of decorators; TS does not support them at all
-    // without this flag.
-    "experimentalDecorators": true,
-
-    // Support generation of source maps. Note: you must *also* enable source
-    // maps in your `ember-cli-babel` config and/or `babel.config.js`.
-    "declaration": true,
-    "declarationMap": true,
-    "inlineSourceMap": true,
-    "inlineSources": true,
+    "extends": "@tsconfig/ember/tsconfig.json",
 
     // The combination of `baseUrl` with `paths` allows Ember's classic package
     // layout, which is not resolvable with the Node resolution algorithm, to

ts/blueprints/ember-cli-typescript/index.js

@@ -148,6 +148,7 @@ module.exports = {
 
     let packages = [
       'typescript',
+      '@tsconfig/ember',
       'ember-cli-typescript-blueprints',
       '@types/ember-resolver',
       '@types/ember__test-helpers',