Don't use declare module for TypeScript types
#127
Conversation
As I understand things, the `declare module` TypeScript syntax creates a globally-importable name and says that any import with that name maps to the given type. This means it usually works for libraries, but breaks down when you have multiple versions of the same library loaded, since they each redefine the same global name. It's really meant for things like Node.js built-in modules. Instead, `.d.ts` files in libraries should just do exports at the top-level, and TypeScript allows different versions of the same library to peacefully coexist in that case. I ran into a dependency hell problem that I think was caused by this issue where decaffeinate pulled in three different versions of magic-string that conflicted. I was able to change the dependency tree so it's just one version, which works in the near term, but this change should prevent that from happening again.
|
Ah, interesting. I think this may have been something to do with the fact that the ES module and the UMD module are slightly different (the ESM has a default and a named export, the CJS has a single |
|
I think this is unrelated to the ES modules vs CJS issue. (Sounds like you're referring to #121?) When TypeScript sees With this change, it's defining the same TypeScript module as before, but rather than saying "associate the module with the global name (But I'm pretty new to TypeScript, so I might be misunderstanding some aspects of it. But I did test this change and it seems to still work. :-) ) I hadn't tried VSCode, but I tried just now (with |
|
Cool — let's roll with it then and cross those bridges if we come to them. Thanks, releasing an update |
|
Thanks! |
As I understand things, the
declare moduleTypeScript syntax creates aglobally-importable name and says that any import with that name maps to the
given type. This means it usually works for libraries, but breaks down when
you have multiple versions of the same library loaded, since they each redefine
the same global name. It's really meant for things like Node.js built-in
modules. Instead,
.d.tsfiles in libraries should just do exports at thetop-level, and TypeScript allows different versions of the same library to
peacefully coexist in that case.
I ran into a dependency hell problem that I think was caused by this issue where
decaffeinate pulled in three different versions of magic-string that conflicted.
I was able to change the dependency tree so it's just one version, which works
in the near term, but this change should prevent that from happening again.