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 alternative isn't having a single more complete package, it's having a few dozens of more complete, overlapping packages that each don't fully satisfy your needs.
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.
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.
It's not a specific package manager. It's the package manager. You use Node.js (or io.js, which is effectively the same as Node.js) to build jQuery, the Node.js package manager is NPM. jQuery is an NPM package and uses NPM's package.json to define its development dependencies.
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.
I don't know how many other ways to say this: Downloading dependencies is not the job of a build system! One should be able to use npm to fetch dependencies, or get them via another means (your system package manager), and the build system shouldn't care. Coupling package managers to build systems is a mistake.
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.