TypeScript's ecosystem of self-bundled typings does not work with npm

[falsandtru]

When npm dependencies have same packages of different versions, tsc throws duplicate identifier errors. TypeScript's ecosystem of packages is weaker than npm, and does not have compatibility with npm. I believe this is a large problem. And this will be a popular problem because npm always install an exact version in resolving dependencies. For example, when depending a@^0.0.2 and a@^0.0.1 as another package's dependency, its project has a@0.0.1 and a@0.0.2. npm can resolve these different versions, but TypeScript cannot.

TypeScript Version:

1.9.0-dev.20160526

[aluanhaddad]

This is a serious problem. But when you say that

because npm always install an exact version in resolving dependencies. For example, when depending a@^0.0.2 and a@^0.0.1 as another package's dependency, its project has a@0.0.1 and a@0.0.2. npm can resolve these different versions, but TypeScript cannot.

it is important to note that the way npm resolves these transitive dependencies is by recursively installing and resolving packages as nested dependencies. Versioning is handled by directory nesting. This is far from ideal and is part of the reason why tools like jspm exist. I'm bringing this up here, in a npm issue, because I think the problem is broader and that a more abstract solution needs to exist.

[mhegazy]

if the declaration files are authored correctly as modules, then there are no issues here. if the declaration file is authored as global, then the conflict in the global scope is what i would expect.

@DanielRosenwasser what did you have in mind marking this as "community tooling"?

[niieani]

@mhegazy Indeed, there might be global declarations, such as node being dependencies of submodules. Perhaps as a simple solution, TypeScript should disregard such global dependencies in case the parent module already has them included? Might not work in all cases, but it's a good start. A better solution would be to somehow have TypeScript wrap all the modules in a similar fashion to the Typings tool, which prevents conflicts between global dependencies.

[mhegazy]

TypeScript wrap all the modules in a similar fashion to the Typings tool, which prevents conflicts between global dependencies.

this is not a viable option. wrapping declarations change their shape and origin and leads to more conflicts down the road. it also changes user code, which makes identifying problems and fixing them much harder.

[mhegazy]

@mhegazy Indeed, there might be global declarations, such as node being dependencies of submodules.

not sure i understand what you mean by this.

[aluanhaddad]

@mhegazy Something I didn't think about for a long time was that the declare module "..." syntax, while modeling the shape of external modules, actually introduced another global namespace in which collisions are as problematic as any other. Given how widespread this practice has become, and given how typings automatically wraps declaration files, I think clear guidance is needed on how to author declaration files correctly. Furthermore, and I'm sorry for beating a dead horse here, but if the answer to that question is "you can only use the proper (non-polluting) form with node, otherwise you need to use a hack" then there's a definite problem that needs to be addressed at the language level.

[mhegazy]

here is the documentation we are adding to the handbook. take a look and let us know if there is something that is missing: microsoft/TypeScript-Handbook#335

[niieani]

@mhegazy What I meant is that dependencies or their dependencies might require an older, conflicting version of a given global typing (e.g. node). Will the TypeScript compiler know to distinguish the in their respectable scopes, or will it cause problems, like the OP described?

[mhegazy]

no. and that is why packages should not rely on specific versions of an @types package, it should be major.minor.* or major.* or just latest for cases like node.