Skip to content
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

Closed
devongovett opened this issue Mar 5, 2021 · 2 comments · Fixed by #21
Closed

Private vs public module fragments #4

devongovett opened this issue Mar 5, 2021 · 2 comments · Fixed by #21

Comments

@devongovett
Copy link

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 in module.js.

I think it may be useful to annotate which module fragments are accessible from outside the file they are defined in. For example:

// Only accessible within this file
module '#private' {
  export function doSomethingPrivate() {}
}

// Accessible from outside the file.
export module '#public' {
  import {doSomethingPrivate} from '#private';

  export function publicFunction() {
    doSomethingPrivate();
  }
}

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?

@ljharb
Copy link
Member

ljharb commented Mar 5, 2021

I would hope they’re all inaccessible by default, like any other expression.

@littledan
Copy link
Member

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 export keyword wouldn't make sense.

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 export, and the referrer has a different URL (ignoring the fragment), then the import would be rejected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants