Live data from Hacker News

Let's Package JQuery: A JavaScript Packaging Dystopian Novella

dustycloud.org

1–10 of 32 posts

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#4
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.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#5

"265 unique packages, all to build jquery!" Oh my goodness.

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.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#6
post #4

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 and C in their own node_modules directories, except that it will avoid installing a copy of C in B's node_modules directory because it already exists in a higher folder.

However, if B and C both depend on D, then NPM will install D in each's node_modules folders. You can run `npm prune` (or `npm dedupe`? I can't remember) to make it lift D up a folder so it only needs one copy.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#7
I fail to see the problem. Just create a .tar.gz with all the dependencies installed and assets compiled, which you can distribute to users that don't care about or don't want to mess around with the build tools.

If I want to build a native application (like git, which I often do) from source, it's not like the situation is much better. I have to install the compiler obviously, and I have to manually install the dependencies.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#8
T.C. and I worked on getting jQuery packaged for Fedora [1].

It's quite painful trying to package npm modules in a way that's suitable for distributions like Red Hat/Fedora/Debian. The dependency tree just goes on and on and on, and there are versioning issues all over the shop. And if you want to run test suites in the package build process then you'd better package mocha, tap, tape, nodeunit, should, vows, expresso, jasmine, supertest etc. And all of their dependencies too. And make sure every test in the test suites for every module pass. By the end of it all, you're a broken, hollow shell of the person you were before, but at least now it's possible to run "yum install js-jquery" and get version 2.1.3 :-)

[1]: https://fedoraproject.org/wiki/Changes/jQuery

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#9
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.

Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella

#10

T.C. and I worked on getting jQuery packaged for Fedora [1]. It's quite painful trying to package npm modules in a way that's suitable for distributions like Red Hat/Fedora/Debian. The dependency tree just goes on and on and on, and there are versioning issues all over the shop. And if you want to run test suites in the package build process then you'd better package mocha, tap, tape, nodeunit, should, vows, expresso…

Honest question, not trolling: why would I want to install a front-end JS lib using a system package manager? What is the use-case for doing this?
Post reply on HN