@tsconfig/ember
v3.0.8
Published
A base TSConfig for working with Ember.
Downloads
76,887
Readme
A base TSConfig for working with Ember.
Add the package to your "devDependencies"
:
npm install --save-dev @tsconfig/ember
yarn add --dev @tsconfig/ember
Add to your tsconfig.json
:
"extends": "@tsconfig/ember/tsconfig.json"
NOTE: You may need to add
"baseUrl": "."
to yourtsconfig.json
to support proper file resolution.
The tsconfig.json
:
{
"$schema": "https://json.schemastore.org/tsconfig",
"docs": "https://guides.emberjs.com/release/typescript/",
"_version": "3.0.0",
// This is the base config used by Ember apps and addons. When actually used
// via Ember CLI (e.g. ember-cli-typescript's blueprint), it additionally has
// `compilerOptions.baseUrl`, `compilerOptions.paths`, and `include` set.
"compilerOptions": {
"target": "es2021",
"module": "esnext",
"moduleResolution": "bundler",
// We don't want to include types dependencies in our compiled output, so tell TypeScript
// to enforce using `import type` instead of `import` for Types.
"verbatimModuleSyntax": true,
// 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,
// Practically, it is *nearly* impossible to have every type-checked
// package in your dependency graph to have compatible types.
// Good stewards of the ecosystem may opt to set this to false and try to
// fix packages with failures, but for most people, the error information
// is inactionable noise.
"skipLibCheck": true,
// --- 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: this is viral and will require anyone downstream of your package
// to *also* set them to true. However, this represents the way that
// bundlers actually work, and is future-compatible with the closest module
// modes: "nodenext" in TS 4.7+ and "mixed" in 5.0+ mode. Since Ember apps
// and addons never emit with `tsc`, this is safe: it makes type-checking do
// the right thing, but does not result in changes to what gets emitted. We
// intentionally leave `esModuleInterop` unset, so that it gets whatever TS
// provides as the default for the currently-specified `module` mode.
"allowSyntheticDefaultImports": 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 tools trying to respect the tsconfig
// to still emit code without breaking on errors.
// Errors are still reported in the CLI when running `tsc` or `glint`,
// but the errors won't prevent code from being emitted.
// This helps hasten development by allowing devs to prototype before coming
// to a decision on what they want their types to be.
"noEmitOnError": false,
// 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,
// Don't implicitly pull in declarations from `@types` packages unless we
// actually import from them AND the package in question doesn't bring its
// own types.
//
// You may wish to override this e.g. with `"types": ["ember-source/types"]`
"types": []
}
}
You can find the code here.