It establishes a standard pattern for exposing npm modules as part of a package’s API: for example, HTTPInternals.NpmModules.request.module is the request module used by http, and its version string can be found at HTTPInternals.NpmModules.request.version.

(I know that users have requested automatically allowing every package to access the npm dependencies of every other package, but I don’t think that’s a good idea. In my opinion, packages should be able to keep their npm dependencies as an internal implementation detail rather than as part of their public API. It should be an active choice to say “In addition to the API I’ve designed, I’m also committing to supporting the entire API of the wrapped package as part of my API”.)

This will go into Meteor 1.0.4. If anyone has any suggestions (for example, about the names we’ve chosen for these features, or anything else) let me know, either here on the forum, or on ReviewBoard (anyone with a RBCommons account should be able to comment on the code review)!

Packages should be able to have their own npm dependencies, but IMHO, they should also be able to share npm dependencies. The distinction for this can be absolute vs range versions. Npm.depends allows only absolute.