3 ms·

I have no less than seventeen different point releases of lodash buried in my node_modules directory for one project. That's completely insane, but every plugi

I have no less than seventeen different point releases of lodash buried in my node_modules directory for one project. That's completely insane, but every plugin we use for something has it's own massive tree of dependencies, which have their own dependencies, ad absurdum, until I've got paths too long for Windows to be able to delete down in there. Not to even get into the clusterfuck that is semver and how the default behavior with npm isn't to pin to a specific version of a package. It's bitten me in the ass several times lately because some dependency of ours will have a new patch version, and it completely breaks everything. I'm living mostly on the back-end, .NET world. NuGet isn't great, but it's a breeze compared to fighting with JS-land. Packages are kept to a reasonable size, rather than fragmenting into micropackages, references only update when you tell them to, and stability is valued. Of course, you've also actually got a standard library, so you don't have to rely on third-party code for basic functionality.

styfle 8y ago
You might find Package Phobia[0] useful. It determines the size of a package before you install it including it's dependencies. Disclaimer: I wrote it. Another good tool to use before you pull in a dependency is this dependency visualization[1]. [0]: https://packagephobia.now.sh https://packagephobia.now.sh [1]: https://npm.anvaka.com https://npm.anvaka.com
Klathmon 8y ago
What package manager are you using, and what version of it? js packages are encouraged to have loose version numbers to prevent the "multiple of the same version" issue from happening, and for applications newer npm (and all versions of yarn) include lockfiles by default that lock in all dependencies to an exact version that is unchanging until you tell it to upgrade. While I won't rehash the same "standard library vs widespread packages" debate again, deps only update when you tell them to now, and you are given the tools to overwrite those versions if needed (for example, you could run a command and force all 17 of those point releases of lodash to use exactly 1). It's obviously not ideal that you'd have to do that, but I still prefer it over not having the choice at all and being stuck in "dll hell" which tends to happen with larger projects in other areas.

styfle 8y ago

You might find Package Phobia[0] useful. It determines the size of a package before you install it including it's dependencies. Disclaimer: I wrote it. Another good tool to use before you pull in a dependency is this dependency visualization[1]. [0]: https://packagephobia.now.sh https://packagephobia.now.sh [1]: https://npm.anvaka.com https://npm.anvaka.com

Klathmon 8y ago

What package manager are you using, and what version of it? js packages are encouraged to have loose version numbers to prevent the "multiple of the same version" issue from happening, and for applications newer npm (and all versions of yarn) include lockfiles by default that lock in all dependencies to an exact version that is unchanging until you tell it to upgrade. While I won't rehash the same "standard library vs widespread packages" debate again, deps only update when you tell them to now, and you are given the tools to overwrite those versions if needed (for example, you could run a command and force all 17 of those point releases of lodash to use exactly 1). It's obviously not ideal that you'd have to do that, but I still prefer it over not having the choice at all and being stuck in "dll hell" which tends to happen with larger projects in other areas.