21–30 of 32 posts
"265 unique packages, all to build jquery!" Oh my goodness.
many of those dependencies are testing related including some large dependencies for virtual dom stuff to mock the browser. Plus it uses grunt which, while I don't really like it, it does have the benefit over make that it works out of the box on windows which is something jquery has to support.
Earlier quoted context omitted.
To be fair, Node/Javascript prefers to have many small packages that do just one thing (hopefully well).
But the packaging burden is the same, regardless of the size of the source code. There's still 265 unique dependencies for a distro to package to build jQuery from source in its entirety. That's rough.
npm install jquery
It would be just as ridiculous to complain about how hard it is to build ffmpeg from source by using npm as the package manager.
Earlier quoted context omitted.
To be fair, Node/Javascript prefers to have many small packages that do just one thing (hopefully well).
Yeah, I have several modules on NPM that are each just a single function (with unit tests!) that I'm interested in using in more than one package. "265 unique packages" could possibly be "265 short functions" on one extreme end.
Earlier quoted context omitted.
But the packaging burden is the same, regardless of the size of the source code. There's still 265 unique dependencies for a distro to package to build jQuery from source in its entirety. That's rough.
Nope. There's nothing rough about npm install jquery If you want to build it from source, use the management tool that jQuery was designed to use, and was designed to support jQuery. It would be just as ridiculous to complain about how hard it is to build ffmpeg from source by using npm as the package manager.
To always use the same versions of every dependency you'll want to shrink wrap. And yes, of course dependencies have dependencies. Software depends on other software. All packaging systems have a tree of dependencies.
>To always use the same versions of every dependency you'll want to shrink wrap. Does "shrink wrap" mean "bundle"? If so, I strongly disagree. It's possible to explicitly use the exact same versions of dependencies without resorting to bundling all the source/binaries. Guix and Nix are particularly well suited for this. >And yes, of course dependencies have dependencies. But you have to admit that the depth of this d…
Depth of tree is reasonable: if you install them at the top.
From the article: "Our deployment and build setups have gotten so complicated that I doubt anyone really has a decent understanding of what is going on, really." There's now a school of thought in the Rust world that it's easier to just build a static executable and ship that.
>There's now a school of thought in the Rust world that it's easier to just build a static executable and ship that. If that's where we're headed, I'm extremely sad. Static linking everything is a lazy non-solution, IMO. Rampant duplication, increased resource usage, etc. Not good.
Earlier quoted context omitted.
Yeah, I have several modules on NPM that are each just a single function (with unit tests!) that I'm interested in using in more than one package. "265 unique packages" could possibly be "265 short functions" on one extreme end.
To what end? It seems like the package overhead would destroy any savings in package size to be able to mix and match rather than just having a larger, more complete package.
And what would a more complete package look like? "AgentME's bag of useful functions"? Many of them don't make sense to group together.
Earlier quoted context omitted.
Yeah, I have several modules on NPM that are each just a single function (with unit tests!) that I'm interested in using in more than one package. "265 unique packages" could possibly be "265 short functions" on one extreme end.
To what end? It seems like the package overhead would destroy any savings in package size to be able to mix and match rather than just having a larger, more complete package.
The overhead is negligible: running `npm install` in production is considered an anti-pattern and because of how npm's dependency resolution works each dependency can have different copies of the same (second order) dependency. The likelihood that there will be version conflicts (and thus duplication) is far smaller when there are smaller more specialised packages instead of a few big ones.
It's not about package size. Nobody cares about package size (except for frontend code but it's fairly easy to pare those deps down to the bare minimum).
Also, nearly all of jQuery's deps are development deps not needed in production. Those deps are only interesting for maintainers -- building jQuery yourself is likely the wrong thing to do. It's only necessary because jQuery doesn't yet expose its "submodules" properly.
Earlier quoted context omitted.
Nope. There's nothing rough about npm install jquery If you want to build it from source, use the management tool that jQuery was designed to use, and was designed to support jQuery. It would be just as ridiculous to complain about how hard it is to build ffmpeg from source by using npm as the package manager.
Having a build process tied to a specific package manager is a big problem.
This isn't really up to debate. There are other package managers for JS, but they aren't replacements for NPM. And no, Meteor doesn't count -- Meteor is its own strange quasi-incompatible microcosm. In fact, some projects which aren't node packages use NPM just to manage development dependencies.
does it mean that if I have 10 modules that depends on exactly the same version of another module (e.g. dependent 1.1.1).. npm will download 1.1.1 10 times? Wouldn't it just use the single package with the correct and share it across? Or the cache is main use to copy the dependent module 10 times.
The same version of the same package isn't ever downloaded multiple times. That's cached. Packages may be installed in multiple locations though. NPM doesn't reinstall dependencies that are already above it in the tree. If A depends on B and C, and B depends on (an overlapping version range of) C and D, then B and C will be installed first in A's node_modules directory, and then NPM will install the dependencies of B…