You do make an excellent case for only exposing the "main"
module, and I think it's been brought up on the packages
thread recently too. The counter-example would be packages
that provide frameworks or toolkits, where each module
provides a particular feature, or where a package has a
reusable component. The "narwhal-lib" package is a great
example. "jack" is a decent example, although its "main"
module does expose the content of a lot of the common
modules. I recently had a case where one package needed
some parsers internally, but those parsers turned out to be
useful in another package. Grabbing the single module was
useful in the short term, although someday there might be a
full enough set of parsers and parser modules to warrant a
separate parsing framework package.
Kris Kowal
> is approximately equivalent to
would be, isn't
> require("narwhal-lib/subpackage")
The trouble with this approach is that every "main" module
effectively becomes a manifest, and all modules of the
subpackage must not only be fetched, but loaded, and
executed, in the order specified by the main module.
Kris Kowal
I think both approaches have merit.
One could add a module handler property to the package spec to restrict
access to arbitrary modules. The handler is bypassed for relative
requires within the package and only used when requiring modules from
outside of the package.
package.json ~ {
"modules": {
"<match>": "<handler>",
"*": "main"
}
}
lib/main.js ~ {
exports.publicapi = require("./subpackage");
}
require("narwhal-lib/publicapi");
By default however I think every module in the package should be
addressable.
Christoph
We do not need this feature for a workable, common package
specification. I would encourage everyone to think minimal,
simple, and as close to featureless as possible. I think we
agree that it needs to be possible in some cases, albeit not
all, to address modules inside mapped packages. Let's leave
it at that and let implementors explore API enforcement.
Kris Kowal
However, I wouldn't want the spec to contain language that *forbids* a
package manager or platform from allowing
require('narwhal/subpackage').
-Mikeal
> --
> You received this message because you are subscribed to the Google Groups "CommonJS" group.
> To post to this group, send email to comm...@googlegroups.com.
> To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
>
>
Without full access to the modules of a package, many of my
packages will not be useful to other systems, and I'm not
willing to maintain a main.js that manifests all of the
module's packages. I'm sure that there are other package
maintainers who will neglect to write a main.js. It is
marginally simpler to not include this feature, but it's a
critical feature.
Since this is a value judgement and the arguments have been
made, it would probably be sufficent to put it to a show of
hands now.
Kris Kowal
--
With npm, I'm *really* considering not defaulting the directories.lib
setting to "lib", and instead only linking the folder if it's
explicitly set in the package.json. In that case, you'd still be able
to get at it if you did
require(".npm/foo/1.2.3/package/path/to/module") but at least that way
it's tucked out of the way.
--i