Easier ways to access the npm modules wrapped by core modules

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)!

5 Likes

Related to this: New package "rocket:module" to provide CJS/AMD/ES6 Modules for Meteor packages with shared NPM dependencies

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.