What about npm users who intend to use jQuery in an AMD environment? There is no CJS-format requirement for npm-published files. AMD can be converted to CJS using nodefy if you need it. The more common use case for jQuery by far is AMD since that's more popular on the client side.

On the existence of dist/cdn the problem is that the map file contains references to the names of the source and minified files. If we don't publish it by that name the person installing jQuery would need to somehow process internal file references in the map file or else it would be invalid.

What about npm users who intend to use jQuery in an AMD environment?

They just use dist/jquery.js or dist/jquery.min.js like the rest of npm users.

(For clarity let's leave exploration of dist/cdn issue for another time.)

This has been discussed at length. See e.g. #1526. We consider npm to be a JS package manager, not just Node.js/io.js package manager and the npm team agrees. Thus, we need to publish the src/ directory for people relying on our AMD modules. Telling those people to just use the full file is not an option. On the other side, if someone doesn't need those modules they may just ignore them.

The dist/cdn directory shouldn't be included, though. We can migrate this bug to say about dist/cdn or close it & open a new one.

OK, I opened #2164 for the dist/cdn issue. This one can be closed.

Hi @mzgol, thanks for clarifying and for opening #2164. Since jquery is so popular and widely used, just a few hundred KB of saved space has a big impact.

On that note, returning to src/ for a minute, after having reviewed all the other related issues like #2164, #1567, #1817, etc, I'm still not clear. What are the use case(s) for relying on the individual AMD modules instead of the full file? This comment from @dmethvin contains the only reference to a use case I could find, which is

Some people want the AMD modules so that they can do a custom build or use requireJS

But people doing a custom build or tinkering with jquery internals will generally want / need to checkout the entire repo anyway, and then use that repo as the npm module. npm link is intended to be used for this purpose - to alias an npm module in development to a full repo.

I'm trying to think of a real life use case that is not naturally covered by npm link but coming up blank. If there is none, then it seems that there is an opportunity to cut down on waste, at least in npm land.

TJ Vantoll wrote a good article on uses of amd modules in jQuery. http://developer.telerik.com/featured/jquery-using-only-what-you-need/

Since jquery is so popular and widely used, just a few hundred KB of saved space has a big impact.

Sure, but:

1. It affects only developers, not final users.
2. Many other packages, e.g. ones used by npm even publish their tests which we don't do. We're far from the most verbose packages and the whole npm package management encourages installation of many different versions of the same package if only one dependency needs an older/newer package version than another dependency.
3. Maintaining multiple packages would add us more work, make us more vulnerable to publishing mistakes etc. We already spend a lot of time on some releases and mistakes do happen (see http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-released-safari-fail-safe-edition/, esp. the paragraph about a broken 2.1.2 release); we publish to npm, Bower, produce copies for CDNs (our and Google's/MS's/etc.). I don't think that the fact that many devs will download more files than they need to justifies making our release system even more complex, especially that our potential mistakes in this complex problem would affect way more people than use our npm package.

But people doing a custom build (...) will generally want / need to checkout the entire repo anyway, and then use that repo as the npm module.

Why? They don't have to reuse our build system, everything is declared in AMD modules so it's consumable by every AMD build system as well. Using a repository as an npm module is not its main intended use case. In the future we'll export ES6 modules which have a chance of being natively understood by io.js (see e.g. nodejs/NG#9). We're slowly moving into that direction.

I see. It's the people who are consuming individual pieces of jquery in production (via AMD, at the moment) who would need to jump through a hoop. At this point in time the cross section of these people and npm users has got to be extremely small, but I do see the dilemma. Thanks.