-
Notifications
You must be signed in to change notification settings - Fork 7
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
Private vs public module fragments #4
Comments
I would hope they’re all inaccessible by default, like any other expression. |
On a pedantic/formal level, module fragments are not expressions; they are declarations which declare entries in the host's module map, not runtime language values. This led me to initially think that the At the same time, at a high level, it does make sense to me to think of module fragments as things which can be made available outside of the module, or kept local to the module. Multiple people have independently made this request for "private" module fragments, and there have also been use cases presented for module fragments which are exported (e.g., tc39/proposal-module-expressions#34). The semantics of exported vs non-exported module fragments would be a little different from normal module exports. Normal exports are JavaScript values which would be on the module namespace object, but these are entries in the module map. The module fragments case would be more like: all of the fragments go in the module map just the same, but when trying to import a module fragment, there would be an extra check: if a module fragment was not declared with |
In the current proposal, my understanding is that module fragments are always publicly accessible outside the file they are bundled in. For example you can do
import './module.js#fragment'
to import something from the#fragment
module defined inmodule.js
.I think it may be useful to annotate which module fragments are accessible from outside the file they are defined in. For example:
This could be especially useful for library bundling usecases where you may have several input modules and wish to produce a single output file but only some of the input modules should be accessible. Node's exports field in package.json allows something like this on the file level, but for bundled libraries, something similar could be useful.
Bundlers like Rollup and Parcel are often used to bundle libraries like this to prevent unintended access to library internals. In a world where bundlers move to using module fragments, I think we'd want a way to preserve these semantics. If private module fragments were possible, we could simply wrap all modules in fragments and concatenate them, and re-export the entry module.
Thoughts?
The text was updated successfully, but these errors were encountered: