Read on Twitter
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...
Here's the OMGTLDR...
1. TypeScript can be JavaScript + TypesIt'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 worthwhileTypeScript 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 worthwhileIf 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 mattersUsing 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 importantIf 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 avoidedGlobal 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 modesA *.d.ts file operates in one of 3 different ways, based on its content. You can classify a given declaration file as either:
1
global2
modular (contains "export")3
the spooky third kind (ultra-rare) https://twitter.com/Jhnnns/status/1309074185839353856
8. Encapsulation of Packages can be violatedNode 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 dependenciesDeclaration 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 dependenciesDeclaration 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 
