WRT PR #3 - ES module detection

[bmeck]

This is the place to discuss specifics of how node will determine the mode a given a source (file / source string). Source string examples include stdin or -e, they do not include JS Function or eval calls. The proposal itself can be seen in PR #3.

Discussions here should regard:

• Ways to detect the module target for a specific source
• Impact of detecting the module on other environments
  • How other environments will provide the detection in the case of interoperability
• Potential incompatibilities introduces for existing workflows with module detection possibilities.
• Transition goals for a time when ES modules are the normal target.

Note: CJS will be the default target of node for the foreseeable future, "normal" here means what developers write daily. This is a constraint that can be easily worked around for a single source via a cli flag to note that the source is an ES module. This flag should not be seen as relevant to the discussion in this thread.

Note: We are only discussing choices that do not require parsing of the source file.

It should not discuss import/export conversion, evaluation ordering, or module path resolution.

[jokeyrhyme]

Is it appropriate to discuss the ".jsm" extension proposal here? Or does it belong elsewhere? Or has that proposal been definitively rejected?

[bmeck]

@jokeyrhyme yes, you can discuss various approaches such as .jsm, package.json, etc. here. .jsm is not rejected, and many still favor it.

[balupton]

I've tried to do a recap of the options for this at https://github.com/nodejs/node/wiki/ES6-Module-Detection-in-Node

Personally, I'm proceeding with the userland solution of editions - with the current implementation of editions, there is import and require syntaxes - https://github.com/bevry/editions/wiki/Syntaxes - that could be used for such detection, a directory property could also be added to each edition, if we go that route.

---

@bmeck thanks for splitting this up

[bmeck]

@balupton lots of those are in the proposal / please avoid putting things that have not been agreed upon in the node wiki as it may confuse people. Feel free to paste all that in here and we will discuss it. I disagree with a lot of pro/con points and discussion should be had on them.

[balupton]

@bmeck point of the wiki page was to summarise all points, not just those agreed upon, so as to avoid having to read the entire previous thread for such depth, it should be expanded rather than truncated - discussion should happen here yes, however I see no wrongdoing with maintaining a comprehensive up to date concise summary of all points

[jmm]

I understand that there are a lot of objections to the idea of trying to inspect the source to detect the format, to the point that in the original thread people keep saying it's a dead issue, off the table. But yet it's still mentioned here, so as long as it's still in the mix I think the export {} idea I mentioned should be in the picture.

Something like a "use module" pragma would impose an authoring tax on every file, even though most ES6 modules will already organically include at least one import|export that unambiguously establishes its type. That'd leave probably just a tiny fraction of modules, like those that are only for side-effects, that require authors to opt-in with some explicit indicator of type. Instead of something invented like "use module" that could just be module syntax: export {}. @balupton Per your wiki, with this suggestion in mind I think the implementation side is the huge obstacle, not the authoring side.

[bmeck]

@jmm @balupton updated the wiki, it was missing a fair amount of information. Noted things that caused rejections like the pragma "use module". Also linked to proposal to answer "still unclear" points. Please read the file in the proposal before making new statements.

[bmeck]

warning, in 2 weeks module proposal for node will be taking file extension unless package.json complexity and workflow concerns are addressed. If those concerns are addressed we will happily delay the decision. I will be confirming against the @nodejs/ctc that this is not a problem in this time as well.

[dead-claudia]

Which one? Or is that still to be determined?

On Thu, Mar 10, 2016, 14:14 Bradley Meck notifications@github.com wrote:

warning, in 2 weeks module proposal for node will be taking file extension
unless package.json complexity and workflow concerns are addressed. If
those concerns are addressed we will happily delay the decision. I will be
confirming against the @nodejs/ctc
https://github.com/orgs/nodejs/teams/ctc that this is not a problem in
this time as well.

—
Reply to this email directly or view it on GitHub
#13 (comment).

[bmeck]

@isiahmeadows https://github.com/nodejs/node/wiki/ES6-Module-Detection-in-Node#option-4-meta-in-packagejson

Notably:

• Node allows requiring files that are not part of packages
• Will persist in perpetuity and have hints of previous Script goal
  • mitigated but present
• Causes tooling to need to perform JSON parsing per module resolution
  • speed mitigated by cache, parser requirement not
• File semantics are no longer self contained to the file

As per the options, they differ for various ways to put things in package.json

[bmeck]

It should be noted that the file extension has a sizable impact as well. It is not with a happy heart I choose between either.

Also, the package.json thing would be confined to node, and we have several people wanting a simple way to determine goal for non-node projects (many of which do not have package.json).

[balupton]

@bmeck "Is there any plans to support files that use both module systems (aka CJS+ES Modules)?" is specifically about a file that supports both, rather than a package that supports both, here is a contrived example:

import a from 'a'
const b = require('b')

export b
module.exports = a

Another phrasing would be, does each file have to be exclusive es modules, or exclusively node modules, and never mix and match in a single file.

This arose once or twice in the other thread, but I couldn't find anything clear about it, hence why it is there, doesn't seem raised in the proposal explicitly - perhaps is implied somewhere and I didn't notice.

Currently with the babel compiling, mixing and matching module systems in individual files is already being done.

---

great work with the wiki updates! 💃

[bmeck]

@balupton that is not supported, @kittens tried that rabbit hole in babel, it is pure zalgo. If you are in the Module goal there is an exports object as specified in the proposal, but it is a ModuleNamespace. require continues to exist in the Module goal as well. Is there a reason you want a mixed goal in particular?