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

Explain dual-instantiation #11

Merged
merged 4 commits into from
Jan 21, 2019
Merged

Conversation

robpalme
Copy link
Contributor

@robpalme robpalme commented Jan 14, 2019

Resolve the open issue of what happens when a file is requested to be loaded in both modes: ESM and CommonJS.

See #1 for discussion.

The wording is under "Dual-mode packages" section title, but the semantics are more for the general topic of dual-mode files. If we're agreed on the behavior, we can relocate the wording into a more appropriate section.

Resolve the open issue of what happens when a file is requested to be loaded in both modes: ESM and CommonJS.

See GeoffreyBooth#1 for discussion.
@GeoffreyBooth
Copy link
Owner

@bmeck do you mind reviewing this?

Copy link

@bmeck bmeck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs some clarification

README.md Outdated
@@ -281,18 +281,14 @@ To preserve backward compatibility, we expect that `node file.js` will continue

A package can be “dual mode” if its `package.json` contains both a `"main"` field and an `"exports"` field (or some other ESM-signifying field). An `import` statement of such a package will treat the package as ESM and ignore the `"main"` field. To explicitly import a dual-mode package via its CommonJS entry point, [`module.createRequireFromPath`][nodejs-docs-modules-create-require-from-path] could be used.

The ESM and CommonJS versions of a dual-mode package are really two distinct packages, and would be treated as such by Node if both were imported. It is an implementation detail to be worked out what Node should do in such a situation. Of particular concern are race conditions that could occur if it might be unpredictable which version (ESM or CommonJS) of a dual-mode package gets loaded first.
The ESM and CommonJS module systems have independent namespaces. Therefore the ESM and CommonJS versions of a file have separate identities when instantiated. The module loader's previous invariant was: a file will only be loaded at-most once within a Node application. This invariant now becomes: a version of a file (ESM or CommonJS) will only be loaded at-most once within a Node application.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused on "previous invariant". What invariant? Also, are we talking purely about how CJS works, because the loader does not guarantee a file on disk is only loaded once (throw on require/case insensitive filesystems/removal from require.cache).

Also, unclear on if

a version of a file (ESM or CommonJS) will only be loaded at-most once within a Node application.

Is trying to state that a file/url can only be loaded once and only in either CJS or ESM but not in both. It seems unlikely that we can stop CJS from loading all sorts of things.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarification. I have attempted a fix.

I'm trying to refer to the resolved specifier identity that gets used as a key in the virtual registry of all instantiated modules (CJS and ESM). This key is effectively being expanded to include a bit that indicates whether the module is CJS or ESM. Maybe you can guide me on the precise terminology.

An alternative mental model (not written up) would be view them as distinct registries (ESM & CJS) and say that require only operates on the CJS registry whereas import/import() can operate on both registries.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are 2 "Registry"s of sorts, the Global Module Map in ESM and require.cache in CJS. They are not intertwined in part due to the ecosystem reliance on require.cache which is not compatible with how ESM modules are keyed or cached.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have reworded in terms of two registries. Please let me know if this is better.

README.md Outdated Show resolved Hide resolved
@GeoffreyBooth
Copy link
Owner

I'm happy to merge in whenever @bmeck is satisfied.

@bmeck
Copy link

bmeck commented Jan 21, 2019

This seems fine.

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 this pull request may close these issues.

3 participants