What do I do about it? And why

[kristojorg]

Hi there, I saw someone tweet about this and thought I'd give it a try. I'm just a bit confused when it's an issue to have multiple versions of a package and how to fix it. Let's say I have 3 versions of Typescript:

❯ npx qnm typescript
typescript 5.1.3 ↰ 6 days ago | 4.9.5 ↰ 4 months ago
├── 4.9.5 ⇡ 4 months ago
├─┬ @vercel/node
│ └── 4.3.4 ⇡ 1 year ago
└─┬ cordova-plugin-ionic
  └── 3.8.3 ⇡ 3 years ago

What should I do about this? I can try updating @vercel/node and cordova-plugin-ionic, but short of that, is there something else I should I? If I don't have a specific problem I'm trying to solve, is this setup okay?

[ranyitz]

Hi @kristojorg!
The short answer is that you shouldn't worry about this, the long answer is a bit more complex.

One of the original goals of the node_module resolution algorithm was to enable multiple versions of the same module. This was (and probably still is) one of the biggest strengths of node. It enabled a library to declare its dependencies and always work correctly regardless of other dependencies that are installed in the same workspace.

The tradeoff of this approach is that you need to download a lot of different versions of the same module, and since the whole industry is built this way, you get a very heavy node_modules directory. It means that installing your dependencies (both locally and in CI) takes more time and becomes a bottleneck to development velocity.

To mitigate that, package managers designed multiple different approaches to deduplicate modules, starting from npm3, pnpm that installs every module once, and yarn PnP that took a completely different approach. btw, qnm won't help you with pnpm/yarn PnP, but most of the industry still uses npm/yarn with the good old node_modules.

The plot thickens as monorepos arrived to solve issues with developing multiple packages in the same repository. Package managers started to hoist dependencies to the root of the monorepo, which works in most cases, but since there are edge cases, you can still decide to no-hoist particular modules.

Doing the optimizations mentioned above may bring issues (build-related / runtime-related). For example, relying on a plugin system where the plugin brought by the user or another library doesn't fit the version of the engine. Or having multiple versions of react on the same react tree.

qnm was created to help debug these sorts of problems.

With that in mind,

What should I do about this?

If you want to deduplicate TypeScript (which can lower your install time) you can do the following:

1. check why @vercel/node bring a year-old version of TypeScript, looking at their repo, the latest version includes the same version that you have in the node_modules so updating it would remove version 4.3.4
2. check why cordova-plugin-ionic brings a 3 years old version of TypeScript, looking at their repo, it seems they specify this old version in their dependencies while not really using it in their code, so 1 solution can be to open an issue for them and ask them to either remove this dependency or update it.

In case you want to forcefully verify you have only 1 version of TypeScript you can use either yarn resolutions or npm overrides

---

But again, you probably have more productive things to do, so if install time is not a blocker for you, I would suggest dealing with this if it becomes problematic.

[kristojorg]

Thank you so much for the thorough explanation @ranyitz ! I appreciate it. This is essentially what I had thought, but wanted to check if there was something I was missing here. You're right that install time isn't a huge bottleneck for us right now, so I probably won't worry about it, but we should make sure to update things like @vercel/node.

Cheers!