Let's Package JQuery: A JavaScript Packaging Dystopian Novella
1–10 of 32 posts
Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella
#2Oh my goodness.
Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella
#3"265 unique packages, all to build jquery!" Oh my goodness.
Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella
#4Re: 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).
Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella
#6does 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.
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
#7If 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
#8It'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 :-)
Re: Let's Package JQuery: A JavaScript Packaging Dystopian Novella
#9There'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
#10T.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…