-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should not expose dependencies package's require #15
Comments
That’s debatable, and fixing that emergent pattern would require significant complication. We would need to separate public and private module identifier name spaces and there would be some overlap. A related issue is that we don’t mimic Node’s module identifier namespace semantics perfectly. That is, in Node, you can only access internal modules with relative module identifiers and dependencies only with top-level module identifiers. If we solve one inconsistency, we can probably solve both. |
It’s worth noting that separating those name spaces would have some impact on how we use module identifiers throughout Montage. |
To add to the debate: dependencies are an implementation detail. One should be able to swap them out without affecting the accesible API. |
We should entertain an experiment in v2. We can separate the internal and external name spaces of a package, and instead of normalizing module identifiers to be relative to the package root, decide whether to use the internal or external name space based on whether the identifier starts with This would be a pretty significant refactor. Would you up for it any time in the next six months @Stuk? |
I can add it to the plate and see what happens :) |
In montage we depend on collections, and currently a user can do require("montage/collections"). This shouldn't be possible
The text was updated successfully, but these errors were encountered: