I wrote a blog post on how @TechAtBloomberg uses TypeScript.

"10 Insights from Adopting TypeScript at Scale"

https://www.techatbloomberg.com/blog/10-insights-adopting-typescript-at-scale/

This is the first time we've really talked about our TypeScript infrastructure, despite it being used by over 300 internal projects. So there is a lot to unpack

Here's the OMGTLDR...

1. TypeScript can be JavaScript + Types

It's easy to take a JS purist approach & use TypeScript solely for erasable types. Use `target:ESNext` & avoid the TS features that affect the emitted JS runtime code.

This separation of concerns is no accident!

2. Keeping up with the Compiler is worthwhile

TypeScript keeps getting better. There's strong incentives to use new versions. Keeping TypeScript up-to-date across your packages ensures declaration file compatibility & allows early impact assessment of nightly/Beta/RC releases.

3. Consistent tsconfig settings are worthwhile

If you maintain a set of packages, it's best to avoid divergence in the TypeScript configurations as much as possible. In some cases mismatched settings can lead to inter-project type conflicts. https://twitter.com/matteocollina/status/1305900193582403585

4. How you specify the location of dependencies matters

Using tsconfig "paths" to define where your dependencies live can have surprising results in the generated declaration files.

Declaring Ambient Modules instead of "paths" side-steps this issue.

https://www.typescriptlang.org/docs/handbook/modules.html#ambient-modules

5. De-duplicating types can be important

If any of your types use pinned "dependencies" in package.json, you may end up with multiple different versions of the types for a given package. This can result in staleness and nominality issues.

6. Implicit Type Dependencies should be avoided

Global types are bad for the same reasons that global variables are bad. Avoid global types where possible.
Prefer modular types that must be imported explicitly.

7. Declaration files have three export modes

A *.d.ts file operates in one of 3 different ways, based on its content. You can classify a given declaration file as either:

1global
2modular (contains "export")
3the spooky third kind (ultra-rare) https://twitter.com/Jhnnns/status/1309074185839353856

8. Encapsulation of Packages can be violated

Node packages can declare multiple entrypoints, e.g. "lodash/pick", "lodash/get"

TypeScript's declaration emit does not respect this, so generated declarations can contain injected imports to private files deep in other packages.

9. Generated declarations can inline types from dependencies

Declaration files generated by TypeScript can contain lots of duplicated types. This is because types are sometimes inlined, rather than being referenced by name from their original location. https://twitter.com/robpalmer2/status/1319188885197422594

10. Generated Declarations can contain non-essential dependencies

Declaration files emitted by TypeScript often contain types & imports that are not relevant to users of your package.

Dead Type Elimination (Tree-Shaking!) can drastically reduce the volume of types you ship

Thanks to the TypeScript team for building such a great technology. Especially to @sheetalkamat @atcb @sanders_n @orta @SeaRyanC @drosenwasser who all helped us out at some point along the way

And thanks to the @TechAtBloomberg folk who built our JS/TS infrastructure @hughcrail @TChetwin @lilitdarbinyan @r_ricard @mkubilayk & @maxheiber