External type definitions should take priority over ones that come with a package

[sindresorhus]

Scenario: Package A doesn't come with any type definitions. Package B uses TypeScript and wants to use package A, so they decide to use an unofficial type definition @types/A. Package A later adds official type definition built-in in a minor release. This breaks package B, as the package A type definitions are different and incompatible with @types/A.

This is why I think TypeScript should prefer @types/A, but warn that package A now comes with types built-in.

For a real-world example of this problem, see chalk/chalk#215.

[aluanhaddad]

One way to ensure an app does not fall prey to this is to use static, full explicit "paths" in "compilerOptions" but that does not work for libraries.

I think using the distance between the declarations and the source code is a reasonable metric to break a tie. Also, I would argue that Moment.js is an example of when this behavior is desirable.
That said, all such approaches obviously have problems and the Chalk issue you bring up attests to this strongly.

A more robust, scalable solution that does not use arbitrary tie-breaking semantics is ultimately going to be needed.

A concept of projects and references is needed. Multiversion support should some day have great enough fidelity that go to definition and whatnot resolve different versions of the same package based on full transitive dependency resolution.

That would be no small feat to implement.

[SamVerschueren]

I agree. If someone explicitly installs another type definition, that one should have precedence on the one shipped with the package because the user is explicit. I agree that a warning should be shown to indicate that it might be a better idea to switch to the native type definitions.

This will prevent errors like this happen in the future and give people time to migrate.

[mhegazy]

As @aluanhaddad noted, this scenario is already supported today using "paths" and "typeRoots". why is not that sufficient?

In general, a declaration file shipped with the package has better chance to be accurate, and will always be favored over one that ships independently. I do not think this behavior should change.
Allowing users to override where the declaration file comes from is a supported scenario as noted above, but you need to set some path mappings in your project.

[donaldpipowitch]

why is not that sufficient?

I guess because people aren't prepared to do that, because they don't know if and when Package A adds its own typings.

[kitsonk]

I guess because people aren't prepared to do that, because they don't know if and when Package A adds its own typings.

There are all sorts of challenges there that TypeScript shouldn't get involved in. I have had to recently pin a couple of versions of things because people don't really respect semver, or they they rely upon packages that don't respect semver, introducing breaking changes. Typings are not wholly dissimilar. source-map recently published versions with it, but they don't properly cover their own code causing breaking changes in my downstream code. I didn't blame TypeScript for resolving the included typings. I blamed the author of the package (though I still need to open an issue to correct the typings).

Any change can cause a breaking change. The logic is correct though, included types trump other sources, overridable by the end user. That is the situation that benefits the most people. If people don't want unexpected changes in their packages (including typings) they should pin their dependencies.

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.