|
1 | 1 | {
|
| 2 | + "extends": "@tsconfig/ember/tsconfig.json", |
2 | 3 | "compilerOptions": {
|
3 |
| - "target": "ES2021", |
4 |
| - "module": "ES2020", |
5 |
| - "moduleResolution": "node", |
6 |
| - |
7 |
| - // Trying to check Ember apps and addons with `allowJs: true` is a recipe |
8 |
| - // for many unresolvable type errors, because with *considerable* extra |
9 |
| - // configuration it ends up including many files which are *not* valid and |
10 |
| - // cannot be: they *appear* to be resolve-able to TS, but are in fact not in |
11 |
| - // valid Node-resolvable locations and may not have TS-ready types. This |
12 |
| - // will likely improve over time |
13 |
| - "allowJs": false, |
14 |
| - |
15 |
| - // --- TS for SemVer Types compatibility |
16 |
| - // Strictness settings -- you should *not* change these: Ember code is not |
17 |
| - // guaranteed to type check with these set to looser values. |
18 |
| - "strict": true, |
19 |
| - "noUncheckedIndexedAccess": true, |
20 |
| - |
21 |
| - // Interop: these are viral and will require anyone downstream of your |
22 |
| - // package to *also* set them to true. If you *must* enable them to consume |
23 |
| - // an upstream package, you should document that for downstream consumers to |
24 |
| - // be aware of. |
25 |
| - // |
26 |
| - // These *are* safe for apps to enable, since they do not *have* downstream |
27 |
| - // consumers; but leaving them off is still preferred when possible, since |
28 |
| - // it makes it easier to switch between apps and addons and have the same |
29 |
| - // rules for what can be imported and how. |
30 |
| - "allowSyntheticDefaultImports": false, |
31 |
| - "esModuleInterop": false, |
32 |
| - |
33 |
| - // --- Lint-style rules |
34 |
| - |
35 |
| - // TypeScript also supplies some lint-style checks; nearly all of them are |
36 |
| - // better handled by ESLint with the `@typescript-eslint`. This one is more |
37 |
| - // like a safety check, though, so we leave it on. |
38 |
| - "noPropertyAccessFromIndexSignature": true, |
39 |
| - |
40 |
| - // --- Compilation/integration settings |
41 |
| - // Setting `noEmitOnError` here allows ember-cli-typescript to catch errors |
42 |
| - // and inject them into Ember CLI's build error reporting, which provides |
43 |
| - // nice feedback for when |
44 |
| - "noEmitOnError": true, |
45 |
| - |
46 |
| - // We use Babel for emitting runtime code, because it's very important that |
47 |
| - // we always and only use the same transpiler for non-stable features, in |
48 |
| - // particular decorators. If you were to change this to `true`, it could |
49 |
| - // lead to accidentally generating code with `tsc` instead of Babel, and |
50 |
| - // could thereby result in broken code at runtime. |
51 |
| - "noEmit": true, |
52 |
| - |
53 |
| - // Ember makes heavy use of decorators; TS does not support them at all |
54 |
| - // without this flag. |
55 |
| - "experimentalDecorators": true, |
56 |
| - |
57 |
| - // Support generation of source maps. Note: you must *also* enable source |
58 |
| - // maps in your `ember-cli-babel` config and/or `babel.config.js`. |
59 |
| - "declaration": true, |
60 |
| - "declarationMap": true, |
61 |
| - "inlineSourceMap": true, |
62 |
| - "inlineSources": true, |
63 | 4 |
|
64 | 5 | // The combination of `baseUrl` with `paths` allows Ember's classic package
|
65 | 6 | // layout, which is not resolvable with the Node resolution algorithm, to
|
|
0 commit comments