doc: capture plan for future phases

[MylesBorins]

Based on Oct 3rd modules meeting. Thinking that we could use this PR as a meta tracking issue and break out discussion or specific features, or groups of features, into their own issues?

Thoughts?

I quickly hacked together some proposals for Phase 2, this is rough and very much open to changes.

Anyone should feel free to push to the branch, try and ensure we have consensus for changes before doing so

[ljharb]

uncontentious

[ljharb]

contentious

[robpalme]

Despite me originally describing phase 4 as the time to resolve contentious issues, I think it might be more helpful to reword:

• Phase 3 will focus on extensible "loaders" and deliver an environment that allows user-land experimentation.
• Phase 4 will focus on addressing the user feedback gathered from the experimentation enabled by Phase 3.

[MylesBorins]

updated based on feedback PTAL

Received some feedback on twitter I found very useful: https://twitter.com/kuvos/status/1048958366989606912

Specifically we should maybe explore -e support in phase 2. Likely would come in somewhere like here --> https://github.com/nodejs/node/blob/master/lib/internal/bootstrap/node.js#L276

This would likely require something like -m to implement

[targos]

s/PhPhase/Phase/

[GeoffreyBooth]

Specifically we should maybe explore -e support in phase 2

We’ve been discussing that as the “--eval“ case, if you search through the issues. Most discussion has revolved around needing something like --mode or --module-mode=esm to tell Node to treat -e/--eval or STDIN input in ESM mode. We can’t treat --experimental-modules itself as the flag, since of course it’ll go away once this is no longer experimental.

This is tied up with the mimes discussion. Whatever new flag we make for this should complement the mimes section in package.json; i.e. back when it was simply just "mode": "esm" it made sense for the flag to be --mode, but wherever the design for mimes ends up as should inform this flag.

[weswigham]

Ah, since it's the eval flag/interactive repl, could we just set it to an esm mode but also provide a require in scope (and a __dirname set to "." and __filename set to [eval])? It'd technically be a break since the REPL is sloppy-mode JS now (ie, allows with statements); but given how a REPL is used, I think it'd be nice if a plain node invocation could just drop you into a context where you could do all the things, as it were. Unless for some reason keeping the repl/eval in sloppy mode by default is incredibly attractive?

[devsnek]

there's also been a proposed spec change for a "repl parse goal". I think we should be careful about the things we try to solve instead of letting others solve.

[weswigham]

@devsnek makes sense; static import semantics and binding make zero sense in a repl context.

[MylesBorins]

closing for #196