You are reading content from Scuttlebutt
@Christian Bundy %SDx0liuYR3dfI15uDCp5KW5nFZKtc1n6r1JY5eBP/Uw=.sha256
Re: %RZW7keS4V

@kas

Good recommendation!

My understanding is that npm does some deduplication by default, but that you can trigger a duplicate by installing dependencies in a specific order over time. For example, in January you could install something that depends on foo@1.x.x which resolves to 1.1.1, and then in February you could install something that depends on foo@1.2.x which resolves to 1.2.2, you could get a duplicate because npm tries to avoid a resource-intensive dedupe unless absolutely necessary.

  • If you need the exact same version of two modules: if you need to assert that require('foo') in one module deep equals require('foo') in another module, you may need to manually dedupe.
  • If you want to save space: this likely isn't an issue for most duplicate modules, but if somehow Electron gets duplicated or something then it would be silly not to dedupe.

I don't think I've ever been in any of the above scenarios, but it's definitely a useful tool because it saves others from having to dedupe (since their npm install will be driven by the lockfile).

Join Scuttlebutt now