ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
ProposalDescription (example, ignore the details)ProsConsParsing complexitySpeedEcosystem changesСlarityFlexibilityFuture VisibilityCritically brokenPackage-less files supportOld Node.js support possible?Browser compatibilityResult?
2
extensionUse *.jsm, *.es, or some other new extension for es6 modules, CJS by default.Very clear indication for users and tools.

This is the best case for people who want to determine if the given file is parsed as a es6 module or not.		Will require everyone to use the new extension in the future.

Will require tooling changes (editors, file associations, build scripts, etc.)

It might not be clear to all the newcomers that this is just standardized js, not some extension of it.		Requires significant ecosystem changes to support the new extension, would introduce a new unregistered (yet?) extension.

Apart from that looks like the perfect solution.
3
content-sniffing (just pragma)Use 'use module' for es6 modules, CJS by default.Very clear indication for users.Will require everyone to use the it in the future.
4
content-sniffing (just import/export)If a file has import/export — es6 module, CJS by default.Does not require changes in user code.Does not work — this blocks some valid es6 modules from existing.Broken.
5
content-sniffingCombine pragma and import/export content-sniffing

Pragma is required only for cases when there is no clear indication.
Works out of the box for the current code.

Like import/export content sniffing, but works (for all cases).		Could have performance impact, but not measured yet.

The presence of import/export affects semantics.

Requires more steps for thirdparties to determine if a file is es6 module or not.		Too complex.

Potentially fragile?

No one wants to implement this.
6
entry metaSingle string where the es6 module entry point for the package is. See: `esnext:main`Very simple and clear.ES6 and CJS files cannot interop at the module level. Only on package level. No path for partial upgrades.

Mode of file is not visible while editing the file itself.

a package.json would be required to interop, and currently require() does not need a package.json - including require('lodash/map') for example.		No package-less files support.

Not able to combine cjs and es modules in one package.
7
package level metaA single opt-in flag in package.json that affects all the package files.Very simple and clear.Lacks flexibility: does not allow to partially mix es6 and CJS modules in one package.

Mode of file is not visible while editing the file itself.		No package-less files support.

Not able to combine cjs and es modules in one package.
8
per-file metaA list of files in package.json that show the modes of all filesLike package-level meta, but flexible.Very verbose.

Mode of file is not visible while editing the file itself.		No package-less files support
9
entry meta + per-file metaBoth an entry point and all es6 modules listed in package.jsonLike package-level meta, but flexible.

Probably the best option (why?) if people wish to preserve the `.js` filetype.		Lacks clarity: it could be confusing to the new user how the file is parsed.

Per-file could get bloated, per-dir could have performance impact (but not measured yet).

a package.json would be required to interop, and currently require() does not need a package.json - including require('lodash/map') for example.		No package-less files support
10
sophisticated meta (package + per-dir + per-file meta)A single flag plus per file or per-dir opt-in for es6 modules.Like package-level meta, but flexible.Lacks clarity: it could be confusing to the new user how the file is parsed.

Per-file could get bloated, per-dir could have performance impact (but not measured yet).		No package-less files support
11
package level meta + extensionCombine meta and extension opt-ins, CJS by default.Like package-level meta, but flexible.Still introduces a new extension.

Ecosystem changes are still there, but would be adopted slower, which actually makes things worse long-term.		Is this really better than just the new extension?
12
package level meta + content-sniffing (pragma)Combine meta and 'use module' opt-ins, CJS by default.Like package-level meta, but flexible.2 different things that could affect module loading semantics.

And still does not work out of the box with the current code.		Even pragma-based content-sniffing is not very great. Also, 2 places.
13
package level meta + content-sniffing (import/export)Combine meta and import/export opt-ins, CJS otherwise.Works out of the box for the current code.2 different things that could affect module loading semantics.

Not flexible if one wants to mix es6 and CJS modules in case if those es6 modules do not have import/export.		Not able to combine cjs and es modules in one package in a generic case.
14
package level meta + content-sniffingCombine meta and content-sniffing, meta would allow users to remove the 'use module' pragma from modules where import/export content-sniffing fails.Works out of the box for the current code.3 different things that could affect module loading semantics.3 different ways is perhaps too many
15
package level meta + extension + content-sniffingCombine all the things. Still CJS by default.Umm. Works? Everyone could use whatever he or she wants (is that good?).Too complex, 4 different things that could affect module loading semantics.

Lacks clarity.

This is the worst case for people who want to determine if the given file is parsed as a es6 module or not.

We will also not get rid of the pragma and the new extension in the forseable future.		Too compex, not better than some other solutions.
16
module.json + extension + entry metaNo package.json changes - a `module.json` file may optionally be present in any directory that contains an array of filenames with glob patterns. Anything in this list is parsed as a module. Anything with .jsm is parsed as a module. Anything in the "module" entry point in package.json is parsed as a module.Allows all the benefits of extensions and meta, and the long-tail tax is a "module" entry point in package.json for modules + module.json with ** in it, and .jsm for package-less files.three separate ways to define it. order of precedence would have to be defined.

still requires tooling changes, both for meta and the extension.
long term we'd have to keep all three, even though the common case would not need much.		3 different ways is perhaps too many
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100