{"id":20637,"date":"2020-11-09T23:56:30","date_gmt":"2020-11-10T04:56:30","guid":{"rendered":"https:\/\/www.bloomberg.com\/company\/stories\/10-insights-adopting-typescript-at-scale\/"},"modified":"2023-08-04T09:17:14","modified_gmt":"2023-08-04T13:17:14","slug":"10-insights-adopting-typescript-at-scale","status":"publish","type":"post","link":"https:\/\/www.bloomberg.com\/company\/stories\/10-insights-adopting-typescript-at-scale\/","title":{"rendered":"10 Insights from Adopting TypeScript at Scale"},"content":{"rendered":"
\n \n\t\n\t\n\t
\n\t\t\n\t\t\t
\n\t
\n \n

by Rob Palmer, JavaScript Infrastructure & Tooling Lead at Bloomberg and Co-chair of TC39<\/em><\/p>\n\n<\/div>\n

\n\t
\n<\/div>\n
\n \n

A few years ago, Bloomberg Engineering decided to adopt TypeScript<\/a> as a first-class supported language. This article shares some of the insights and lessons we learned during this journey.<\/p>\n

The headline is that we found TypeScript to be a strong net positive! Please keep that in mind when reading about some of the surprising corners we explored. As engineers, we are naturally attracted to seeing, solving and sharing problems, even when we’re having a good time?<\/p>\n\n<\/div>\n

\n \"A\"A\n \n<\/figure>\n
\n \n

Background<\/h2>\n

Bloomberg already had a colossal investment in JavaScript before TypeScript even existed – more than 50 million lines of JS code. Our main product is the Bloomberg Terminal, which contains more than 10,000 apps. The variety of apps is huge, ranging from the display of intensive real-time financial data and news to interactive trading solutions and many forms of messaging. Back in 2005, the company started migrating those apps from Fortran and C\/C++ to server-side JavaScript, with client-side JavaScript arriving around 2012. Today, we have more than 2,000 software engineers at the company writing JavaScript.<\/p>\n\n<\/div>\n

\n \"The\"The\n
The Bloomberg Terminal<\/figcaption>\n<\/figure>\n
\n \n

Transitioning this scale of codebase from plain JavaScript to TypeScript is a big deal. So we worked hard to ensure there was a thoughtful process that would keep us aligned with standards and preserve our existing capabilities to evolve and deploy our code quickly and safely.<\/p>\n

If you’ve ever been part of a technology migration in a large company, you may be used to heavy-handed project management being used to force progress from reluctant teams who would rather be working on new features. We found that adopting TypeScript was something altogether different. Engineers were self-starting conversions and championing the process! When we launched the beta version of our TypeScript platform support, more than 200 projects opted into TypeScript in the first year alone. Zero projects went back.<\/p>\n\n<\/div>\n

\n \n

What makes this usage of TypeScript special?<\/h2>\n

In addition to scale, something that makes this integration of TypeScript unique is that we have our own JavaScript runtime environment. This means that, in addition to well-known JavaScript host environments, such as browsers and Node, we also embed the V8 engine and Chromium directly to create our own JavaScript platform. The upside of this situation is that we can offer a simple developer experience in which TypeScript is supported directly by our platform and package ecosystem. Ryan Dahl’s Deno pursues similar ideas by putting TypeScript compilation into the runtime, whereas we keep it in tooling that is versioned independently of the runtime. An interesting consequence is that we get to explore what it’s like to exercise the TypeScript compiler in a standalone JS environment that spans both client and server and that does not use Node-specific conventions (e.g., there is no node_modules<\/code> directory).<\/p>\n

Our platform supports an internal ecosystem of packages that uses a common tooling and publishing system. This allows us to encourage and enforce best practices, such as defaulting to TypeScript’s “strict mode,” as well as ensuring global invariants. For example, we guarantee that all published types are modular rather than global. It also means that engineers can focus on writing code rather than needing to figure out how to make TypeScript play nicely with a bundler or test framework. DevTools and error stacks use sourcemaps correctly. Tests can be written in TypeScript and code coverage is accurately expressed in terms of the original TypeScript code. It just works.<\/p>\n

We aim for regular TypeScript files to be the single source of truth for our APIs, as opposed to maintaining handwritten declaration files. This means we have a lot of code leaning heavily on the TypeScript compiler’s automatic generation of .d.ts<\/code> declaration files from TypeScript source code. So when declaration-emit is not ideal, we notice it, as you will see.<\/p>\n\n<\/div>\n

\n \n

Principles<\/h2>\n

Let’s outline three key principles we’re striving for.<\/p>\n

\u2696\ufe0f Scalability:<\/b> Development speed should be kept high as more packages adopt TypeScript. Time spent installing, compiling, and checking code should be minimized.<\/p>\n

\u262e\ufe0f Ecosystem Coherence:<\/b>\u00a0Packages should work together. Upgrading dependencies should be pain-free.<\/p>\n

\ud83d\udcc4 Standards Alignment:<\/b> We want to stick with standards, such as ECMAScript, and be ready for where they might go next.<\/p>\n

The discoveries that surprised us usually came down to cases where we weren’t sure if we could preserve these principles.<\/p>\n\n<\/div>\n

\n \n

10 Learning Points<\/h2>\n
\n

1. TypeScript can be JavaScript + Types<\/strong><\/h3>\n

Over the years, the TypeScript team has actively pursued the adoption of and alignment with standard ECMAScript syntax and runtime semantics. This leaves TypeScript to concentrate on providing a layer of type syntax and type-checking semantics on top of JavaScript. The responsibilities are clearly separated: TypeScript = JavaScript + Types!<\/strong><\/p>\n

This is a wonderful model. It means that the compiler output is human-readable JavaScript, just like the programmer wrote. This makes debugging production code easy even if you don’t have the original source code. It means you do not need to worry that choosing TypeScript might cut you off from future ECMAScript<\/a> features. It leaves the door open to runtimes, and maybe even future JavaScript engines, that can ignore the type syntax and therefore “run” TypeScript natively. A simpler developer experience is in sight!<\/p>\n

Along the way, TypeScript was extended with a small number of features that don’t quite fit this model. enum<\/code>, namespace<\/code>, parameter properties<\/em>, and experimental decorators<\/em>\u00a0all have semantics that require them to be expanded into runtime code that, in all likelihood, will never be directly supported by JavaScript engines.<\/p>\n

\ud83d\udcc4 Standards Alignment \u2754<\/b><\/p>\n

This is not a big deal. The TypeScript Design Goals<\/a> articulate the need to avoid introducing more runtime features in the future. One member of the TypeScript team, Orta<\/a>, created a meme-slide to emphasize this recognition.<\/p>\n\n<\/div>\n

\n \"One\"One\n
One member of the TypeScript team, Orta, created a meme-slide to emphasize the need to avoid introducing more runtime features in the future (as per the TypeScript Design Goals).<\/figcaption>\n<\/figure>\n
\n \n

Our toolchain addresses this set of undesirable features by preventing their use. This ensures that our growing TypeScript codebase is truly JS + Types.<\/p>\n

\ud83d\udcc4 Standards Alignment \u2714\ufe0f<\/b><\/p>\n\n<\/div>\n

\n\t
\n<\/div>\n
\n \n

2. Keeping up with the Compiler is worthwhile<\/strong><\/h3>\n

TypeScript evolves rapidly<\/a>. New versions of the language introduce new type-level features, add support for JavaScript features, improve performance and stability, as well as improve the type-checker to find more type errors. So there’s a lot of enticement to use new versions!<\/p>\n

Whilst TypeScript strives to preserve compatibility, these type-checking improvements represent breaking changes to the build process as new errors are identified in codebases that previously appeared error-free. Upgrading TypeScript therefore requires some intervention to get these benefits.<\/p>\n

There is another form of compatibility to consider, which is inter-project compatibility. As both JavaScript and TypeScript syntaxes evolve, declaration files need to contain new syntax.<\/p>\n

If a library upgrades TypeScript and starts producing modern declaration files with new syntax, application projects using that library will fail to compile if their version of TypeScript does not understand that syntax. An example of new declaration syntax is the emit of getter\/setter accessors in TypeScript 3.7<\/a>. These are not understood by TypeScript 3.5 or earlier. This means that having an ecosystem of projects using different compiler versions is not ideal.<\/p>\n

\u262e\ufe0f Ecosystem Coherence \u2754<\/b><\/p>\n

At Bloomberg, codebases are spread across various Git repositories that use common tooling. Despite not having a monorepo, we do have a centralized registry of TypeScript projects. This allowed us to create a Continuous Integration (CI) job to “build the world” and verify the build-time and run-time effects of compiler upgrades on every TypeScript project.<\/p>\n

This global checking is very powerful. We use this to assess Beta and RC releases of TypeScript to discover issues ahead of general release. Having a diverse corpus of real-world code means we also find edge cases. We use this system to guide fix-ups to projects ahead of the compiler upgrade, so that the upgrade itself is flawless. So far, this strategy has worked well and we have been able to keep the entire codebase on the latest version of TypeScript. This means we have not needed to employ mitigations such as downlevelling DTS files<\/a>.<\/p>\n

\u262e\ufe0f Ecosystem Coherence \u2714\ufe0f<\/b><\/p>\n\n<\/div>\n

\n\t
\n<\/div>\n
\n \n

3. Consistent tsconfig<\/code> settings are worthwhile<\/strong><\/h3>\n

Much of the flexibility provided by tsconfig<\/code> is to allow you to adapt TypeScript to your runtime platform. In an environment where all projects are targeting the same evergreen runtime, it turns out to be a hazard for each project to configure this separately.<\/p>\n

\u262e\ufe0f Ecosystem Coherence \u2754<\/b><\/p>\n

Therefore we made our toolchain responsible for generating tsconfig<\/code> at build time with “ideal” settings. For example, \"strict\"<\/a><\/code> mode is enabled by default to increase type-safety. \"isolatedModules\"<\/code><\/a> is enforced to ensure our code can be compiled quickly by simple transpilers that operate on a single file at a time.<\/p>\n

A further benefit of treating tsconfig<\/code> as a generated file, rather than as a source file, is that it permits higher-level tooling to flexibly link together multi-project “workspaces” by taking responsibility for defining options such as \"references\"<\/a><\/code> and \"paths\"<\/a><\/code>.<\/p>\n

There is some tension here, as a minority of projects wanted the ability to make customizations such as switching to looser modes to reduce the migration burden.<\/p>\n

Initially we tried to cater to these requests and gave access to a small number of options. Later we found that this resulted in inter-package conflicts, when declaration files built using one set of options were consumed by a package using different options. Here’s one example.<\/p>\n

It’s possible to create a conditional type that is directed by the value of \"strictNullChecks\"<\/code><\/a>.<\/b><\/p>\n\n<\/div>\n

\n \n
\n
type<\/span> A = unknown extends {} ? string : number;<\/span><\/pre>\n<\/div>\n\n<\/div>\n
\n    \n    
If\u00a0\"strictNullChecks\"<\/code> are enabled, then A is a number<\/code>.\u00a0If \"strictNullChecks\"<\/code> are disabled, then A is a string<\/code>.\u00a0This code breaks if the package exporting this type is not using the same strictness settings as the package importing it.<\/p>\n
This is a simplified example of a real-life issue we faced.\u00a0As a result, we chose to deprecate the flexibility on strictness modes in favour of having consistent configs for all projects.<\/p>\n
\u262e\ufe0f Ecosystem Coherence \u2714\ufe0f<\/b><\/p>\n\n<\/div>\n
\n\t
\n<\/div>\n
\n    \n    
4. How you specify the location of dependencies matters<\/strong><\/h3>\n
We needed the ability to explicitly declare the location of our dependencies to TypeScript. This is because our ES module system does not rely on the Node file-system convention of finding dependencies by walking up a series of directories named node_modules<\/code>.<\/p>\n
We needed the ability to declare a mapping of bare-specifiers (e.g., \"lodash\"<\/code>) to directory locations on disk (\"c:dependencieslodash\"<\/code>). This is similar to the problem that import maps<\/a>\u00a0attempt to solve for the Web. At first, we tried using the \"paths\"<\/a><\/code> option in tsconfig<\/code>.<\/p>\n\n<\/div>\n
\n    \n    
\n
\/\/ tsconfig.json<\/span>\r\n  \"paths\"<\/span>: {<\/span>\r\n    \"lodash\"<\/span>: [ <\/span>\"..\/..\/dependencies\/lodash\"<\/span> ]<\/span>\r\n  }<\/span><\/pre>\n<\/div>\n\n<\/div>\n
\n    \n    
This worked great for nearly all use cases. However, we discovered this degraded the quality of generated declaration files. The TypeScript compiler necessarily injects synthetic import statements into declaration files to allow for composite types – where types can depend on types from other modules. When the synthetic imports reference types in dependencies, we found the \"paths\"<\/code> approach injected a relative path (import(\"..\/..\/dependencies\/lodash\")<\/code>) rather than preserving the bare-specifier (import \"lodash\"<\/code>). For our system, the relative location of external package typings is an implementation detail that may change, so this was unacceptable.<\/p>\n
\u262e\ufe0f Ecosystem Coherence \u2754<\/b><\/p>\n
The solution we found was to use Ambient Modules<\/a>:<\/p>\n\n<\/div>\n
\n    \n    
\n
\/\/ ambient-modules.d.ts<\/span>\r\ndeclare<\/span> module<\/span> \"lodash\"<\/span> {<\/span>\r\n  export<\/span> *<\/span> from<\/span> \"..\/..\/dependencies\/lodash\"<\/span>;<\/span>\r\n  export<\/span> default<\/span> from <\/span>\"..\/..\/dependencies\/lodash\"<\/span>;<\/span>\r\n}<\/span><\/pre>\n<\/div>\n\n<\/div>\n
\n    \n    
Ambient Modules are special. TypeScript’s declaration-emit preserves references to them rather than converting them to a relative path.<\/p>\n
\u262e\ufe0f Ecosystem Coherence \u2714\ufe0f<\/b><\/p>\n\n<\/div>\n
\n\t
\n<\/div>\n
\n    \n    
5. De-duplicating types can be important<\/strong><\/h3>\n
App performance is critical, so we try to minimize the volume of JS that apps load at runtime. Our platform ensures that only one version of a package is used at runtime. This de-duplication of versions means that a given package cannot “freeze” or “pin” their dependencies. Consequently, this means packages must preserve compatibility over time.<\/p>\n
We wanted to provide the same “exactly-one” guarantee for types to ensure that, for a given compilation of a project, the type-check would only ever consider one single version of a package\u2019s dependencies. In addition to compile-time efficiency, the motivation was to ensure the type-checked world better reflects the runtime world. We specifically wanted to avoid staleness issues and “nominality hell,” in which two incompatible versions of nominal types are imported via a “diamond pattern”. This is a hazard that will likely grow as ecosystem adoption of nominal types increases.<\/p>\n
\u2696\ufe0f Scalability \u2754<\/b><\/p>\n
\u262e\ufe0f Ecosystem Coherence \u2754<\/b><\/p>\n
We wrote a deterministic resolver that selects exactly one version of each dependency to type against based on the declared version constraints of the package being built.<\/p>\n
\u2696\ufe0f Scalability \u2714\ufe0f<\/b><\/p>\n
\u262e\ufe0f Ecosystem Coherence \u2714\ufe0f<\/b><\/p>\n
This means the graph of type dependencies is dynamically assembled – it is not frozen. Whilst this unpinned dependency approach provides benefits and avoids some hazards, we later learned that it can introduce a different hazard due to subtle behavior in the TypeScript compiler. See 9.<\/strong> Generated declarations can inline types from dependencies<\/strong><\/em>\u00a0to learn more.<\/p>\n
These trade-offs and choices are not specific to our platform. They apply equally to anyone publishing to DefinitelyTyped\/npm, and are determined by the aggregate effect of each package’s version constraints expressed in package.json \"dependencies\"<\/code>.<\/p>\n\n<\/div>\n
\n\t
\n<\/div>\n
\n    \n    
6. Implicit Type Dependencies should be avoided<\/strong><\/h3>\n
It’s easy to introduce global types in TypeScript. It’s even easier to depend on global types. If left unchecked, this means it is possible for hidden coupling to occur between distant packages. The TypeScript Handbook calls this out as being “somewhat dangerous.”<\/a><\/p>\n
\u2696\ufe0f Scalability \u2754<\/b><\/p>\n
\u262e\ufe0f Ecosystem Coherence \u2754<\/b><\/p>\n\n<\/div>\n
\n    \n    
\n
\/\/ A declaration that injects global types<\/span>\r\ndeclare<\/span> global {<\/span>\r\n  interface<\/span> String {<\/span>\r\n    fancyFormat(opts?: StringFormatOptions): string;<\/span>\r\n  }<\/span>\r\n}<\/span>\r\n\r\n\/\/ Somewhere in a file far, far away...<\/span>\r\nString.fancyFormat();  <\/span>\/\/ no error!<\/span><\/pre>\n<\/div>\n\n<\/div>\n
\n    \n    
The solution to this is well-known: prefer explicit dependencies over global state. TypeScript has provided support for ECMAScript import<\/code> and export<\/code> statements for a long time, which achieve this goal.<\/p>\n
So the only remaining need was to prevent accidental creation of global types. Thankfully, it is possible to statically detect each of the cases where TypeScript permits the introduction of global types. So, we were able to update our toolchain to detect and error in the cases where these are used. This means we can safely rely on the fact that importing a package’s types is a side-effect-free operation.<\/p>\n
\u2696\ufe0f Scalability \u2714\ufe0f<\/b><\/p>\n
\u262e\ufe0f Ecosystem Coherence \u2714\ufe0f<\/b><\/p>\n\n<\/div>\n
\n\t
\n<\/div>\n
\n    \n    
7. Declaration files have three export modes\u00a0<\/strong><\/h3>\n
Not all declaration files are equal. A declaration file operates in one of three modes<\/a>, depending on the content; specifically the usage of import<\/code> and export<\/code> keywords.<\/p>\n
    \n
  1. global —<\/b> A declaration file with no usage of import<\/code> or export<\/code> will be considered to be global<\/i>.\u00a0Top-level declarations are globally exported.<\/li>\n
  2. module —<\/b> A declaration file with at least one export<\/code> declaration will be considered to be a module. Only the export<\/code> declarations are exported and no globals are defined.<\/li>\n
  3. implicit exports —<\/b> A declaration file that has no export<\/code> declarations, but does use import<\/code> will trigger defined-yet-undocumented behaviour. This means that top-level declarations are treated as named export<\/code> declarations and no globals are defined.<\/li>\n<\/ol>\n
    We do not use the first mode. Our toolchain prevents global declaration files (see previous section: 6.<\/strong> Implicit Type Dependencies should be avoided<\/strong><\/em>). This means all declaration files use ES module syntax.<\/p>\n
    \u2696\ufe0f Scalability \u2714\ufe0f<\/b><\/p>\n
    \u262e\ufe0f Ecosystem Coherence \u2714\ufe0f<\/b><\/p>\n
    \ud83d\udcc4 Standards Alignment \u2714\ufe0f<\/b><\/p>\n
    Perhaps surprisingly, we found the slightly-spooky third-mode to be useful. By adding just a single-line self-import to the top of ambient declaration files, you can prevent them from polluting the global namespace: import {} from \".\/<my-own-name>\";<\/code>. This one-liner made it trivial to convert third-party declarations, such as lib.dom.d.ts<\/code>, to be modular and avoided the need to maintain a more complex fork.<\/p>\n
    The TypeScript team do not seem to love the third-mode<\/a>, so consider avoiding it where possible.<\/p>\n\n<\/div>\n
    \n\t
    \n<\/div>\n
    \n    \n    
    8. Encapsulation of Packages can be violated<\/strong><\/h3>\n
    As explained earlier (in 5. De-duplicating types can be important<\/em><\/strong>), our use of unpinned dependencies means it is important for our packages to preserve not only runtime-compatibility, but also type-compatibility over time. That’s a challenge, so to make this preservation of compatibility practical, we have to really understand which types are exposed and must be constrained in this way. A first step is to explicitly differentiate public vs. private modules.<\/p>\n
    Node recently gained this capability in the form of the package.json \"exports\"<\/code> field<\/a>. This defines an encapsulation boundary by explicitly listing the files that are accessible from outside the package.<\/p>\n
    Today, TypeScript is not aware of package exports<\/i> and so does not have the concept of which files within a dependency are considered public or not. This becomes a problem during declaration generation, when TypeScript synthesizes import statements to transitive types in the emitted .d.ts<\/code> file. It is not acceptable for our .d.ts<\/code> files to reference private files in other packages. Here’s an example of it going wrong.<\/p>\n\n<\/div>\n
    \n    \n    
    \n
    \/\/ index.ts<\/span>\r\nimport<\/span> boxMaker <\/span>from<\/span> \"another-package\"<\/span>\r\nexport<\/span> const<\/span> box = boxMaker();<\/span><\/pre>\n<\/div>\n\n<\/div>\n
    \n    \n    
    The above source can lead to tsc<\/code> emitting the following undesirable declaration.<\/p>\n\n<\/div>\n
    \n    \n    
    \n
    \/\/ index.d.ts<\/span>\r\nexport<\/span> const<\/span> box : import(<\/span>\"another-package\/private\"<\/span>).Box<\/span><\/pre>\n<\/div>\n\n<\/div>\n
    \n    \n    
    This is bad because \"another-package\/private\"<\/code> is not part of that package’s compatibility promise, so might be moved or renamed without a SemVer major bump.\u00a0TypeScript today has no way of knowing it generated a fragile import.<\/p>\n
    \u262e\ufe0f Ecosystem Coherence \u2754<\/b><\/p>\n
    We mitigate this problem using two steps:<\/p>\n
    1. Our toolchain informs the TypeScript resolver of the intentionally-public bare-specifier paths that point to dependencies (e.g., \"lodash\/public1\"<\/code>, \"lodash\/public2\"<\/code>). We ensure TypeScript knows about the full set of legitimate dependency entry-points by silently adding type-only import statements to the bottom of the TypeScript files just before they flow into the compiler.<\/p>\n\n<\/div>\n
    \n    \n    
    \n
    \/\/ user's source code<\/span>\r\n\r\n\/\/ injected by toolchain to assist declaration emit<\/span>\r\nimport<\/span> type <\/span>*<\/span> as<\/span> __fake_name_1 <\/span>from<\/span> \"lodash\/public1\"<\/span>;<\/span>\r\nimport<\/span> type <\/span>*<\/span> as<\/span> __fake_name_2 <\/span>from<\/span> \"lodash\/public2\"<\/span>;<\/span><\/pre>\n<\/div>\n\n<\/div>\n
    \n    \n    
    When generating references to inferred transitive types, TypeScript’s declaration emit will prefer to use these existing namespace identifiers rather than synthesizing imports to private files.<\/p>\n
    2. Our toolchain generates errors if TypeScript generates a path to a file in a dependency that we know is private. This is analogous to the existing TypeScript errors emitted when TypeScript realizes that it is generating a potentially hazardous path to a dependency.<\/p>\n\n<\/div>\n
    \n    \n    
    error TS2742:<\/span> The inferred type of '<\/span>...<\/span>'<\/span> cannot be named without a reference to '<\/span>...<\/span>'<\/span>.<\/span>\r\nThis is likely not portable.<\/span> A type annotation is necessary.<\/span>\r\n<\/pre>\n\n<\/div>\n
    \n    \n    
    This informs the user to work around the issue, by explicitly annotating their exports. Or, in some cases, they need to update the dependency to publicise internal types by directly exporting them from a public package entrypoint.<\/p>\n
    \u262e\ufe0f Ecosystem Coherence \u2714\ufe0f<\/b><\/p>\n
    We look forward to TypeScript gaining first-class support for entrypoints so that workarounds like this are unnecessary.<\/p>\n\n<\/div>\n
    \n\t
    \n<\/div>\n
    \n    \n    
    9. Generated declarations can inline types from dependencies<\/strong><\/h3>\n
    Packages need to export .d.ts<\/code> declarations so that users can consume them. We choose to use the TypeScript declaration<\/code> option to generate .d.ts<\/code> files from the original .ts<\/code> files. Whilst it’s possible to hand-write and maintain .d.ts<\/code> sibling files alongside regular code, this is less preferable because it is a hazard to keep them synchronized.<\/p>\n
    TypeScript’s declaration emit works well most of the time. One issue we found was that sometimes TypeScript will inline types from a dependency into the generated types (#37151)<\/a>. This means the type definition is relocated and potentially duplicated, rather than being referenced via an import statement. With structural typing, the compiler is not compelled to ensure types are referenced from one definition site – duplication of these types can be ok.<\/p>\n
    We have seen extreme cases<\/a> where this duplication has inflated declaration files from 7KB to 700KB.\u00a0That’s quite a lot of redundant code to download and parse.<\/p>\n
    \u00a0\u2696\ufe0f Scalability \u2754<\/b><\/p>\n
    Inlining of types within a package is not an ecosystem problem, because it is not externally visible. It becomes problematic when types are inlined across package boundaries, because it couples those two specific versions together. In our unpinned package system, packages can evolve independently. This means there is a risk of type incompatibility and, in particular, a risk of type staleness.<\/p>\n
    \u262e\ufe0f Ecosystem Coherence \u2754<\/b><\/p>\n
    Through experimentation, we discovered potential techniques to prevent inlining of type declarations, such as:<\/p>\n