-
Notifications
You must be signed in to change notification settings - Fork 0
/
tsconfig.json
101 lines (91 loc) · 3.58 KB
/
tsconfig.json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
{
"compilerOptions": {
"target": "ES2021",
"module": "ES2020",
"moduleResolution": "node",
// Trying to check Ember apps and addons with `allowJs: true` is a recipe
// for many unresolveable 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-resolveable 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": true,
"esModuleInterop": true,
// --- 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,
// The combination of `baseUrl` with `paths` allows Ember's classic package
// layout, which is not resolveable with the Node resolution algorithm, to
// work with TypeScript.
"baseUrl": ".",
"paths": {
"dummy/tests/*": [
"tests/*"
],
"dummy/*": [
"tests/dummy/app/*",
"app/*"
],
"@opendatafit/ember-codemirror-modifier": [
"addon"
],
"@opendatafit/ember-codemirror-modifier/*": [
"addon/*"
],
"@opendatafit/ember-codemirror-modifier/test-support": [
"addon-test-support"
],
"@opendatafit/ember-codemirror-modifier/test-support/*": [
"addon-test-support/*"
],
"*": [
"types/*"
]
}
},
"include": [
"app/**/*",
"addon/**/*",
"tests/**/*",
"types/**/*",
"test-support/**/*",
"addon-test-support/**/*"
]
}