ember.json

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Ember",
  "docs": "https://docs.ember-cli-typescript.com",
  "_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,

    // --- 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": ["node"]`
    // if your project has build-time elements that use NodeJS APIs.
    "types": []
  }
}