npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2025 – Pkg Stats / Ryan Hefner

@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 your tsconfig.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.