Why so many @types packages for Ember but only one ember-source?

[machty]

The Installation docs and Understanding the @types Package Names
sort of touch on these packages being installed, but in the end, why do we need 20+ types packages for Ember when all you need to install the Ember source code is "ember-source"?

Relatedly, I manage a monorepo at work (6 apps + 2 addons in a yarn workspace):

1. Do all of the apps need these 20+ types packages? (I believe the answer is yes; alternatively some scheme with putting them in addons might work but I have doubts)
2. What's the best method for mass update these apps to the same packages? There are scripts / lints I can use to ensure my monorepo packages consume the same dependency versions, but I didn't know if that was suitable for ember-cli-typescript upkeep or whether I needed to run ember g ember-cli-typescript for each one, or?

[chriskrycho]

The short answer is: so that autocomplete works "out of the box".

By default, tools powered by the TS Language Service do not auto-import from your transitive dependencies—which is as you want, because you only want to suggest completions from your direct dependencies, so that you don't get broken if your direct dependencies' relationship to their transitive dependencies change.

This is essentially a knock-on effect of the fact that Ember ships the umbrella package but that you literally never import directly from ember-source.

There are other ways we could work around this. For example, we could bundle all the definitions with a single ember-source package… but for auto-complete to work "out of the box", you would then need to add (in some types file) all the imports for all the @ember/* packages. However, this approach also allows people to depend types-wise at the level of granularity they use, which leads to the second part of your question:

• You only need the @types packages for the things you actually import and use. If you never use @ember/array, you don't need @types/ember__array. The blueprint is designed to get you up and running with a normal Ember app/addon setup, so we install all the types that correspond to the default blueprint.

• Your best bet in a mono-repo is to manage them at the root level, with a major version requirement that you keep in sync across the packages within the repo, and to force a single top-level resolution for the @types dependencies in the repo-level package.json.

All of these considerations should become substantially easier as we move to shipping types natively from the packages.

[machty]

Thank you for the response!

I'm wary of moving the type dependencies to the root package because I've been burned too many times by ember-cli expecting dependencies to be present in the app's package.json file in order for everything to be wired up properly in the ember-cli build tooling; are you certain what you expected would work?

[chriskrycho]

Yes:

1. In principle: They are not actually runtime dependencies and accordingly are not consumed by ember-cli at all. They’re only consumed by the type-checking process spun up by ember-cli-typescript.

2. In practice: We know that works from a variety of apps doing it that way, including the one I maintain!

[machty]

@chriskrycho What about the various .d.ts files generated per-app? These appear to be largely duplicates of each other; can they be consolidated/centralized in a monorepo?

[machty]

And is using extends in the app tsconfig.json (to inherit from some tsconfig.json in a shared parent folder) a good idea?