I know that users often want to have direct access to some of the npm modules that Meteor packages rely on. For example, accessing the full Mongo API, using connect middleware, or using the full range of the request API, such as the encoding parameter.
A change to enable all these things is currently in code review: https://rbcommons.com/s/meteor/r/13/diff/1/
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)!