initial GOALS declaration

[bmeck]

No description provided.

[bmeck]

@WebReflection import() is supplied by the JS spec itself and doesn't differ from import in the spec for resolution mechanics and is available in both Script and Module goal symbols. I don't think there is anything really to bring up about it goal wise. Is there something we should call out?

[WebReflection]

import() is supplied by the JS spec itself and doesn't differ from import in the spec for resolution mechanics

well, import(...) in Web land is the only way to bring ESM into non ESM scripts. That's quite a huge different to me, 'cause you can use import(...) everywhere, implying you are opting into ESM world.

This is at least the meaning of dynamic import(...) for the Web VS static import.

Are we going to ignore this? If not, there should be some goal around it, maybe not at the first iteration?

[bmeck]

@WebReflection I'm not sure I understand. By JS spec, CJS has access to import(specifier) to load any Abstract Module Record it resolves to.

[devsnek]

it should also be noted that node already supports import()

[WebReflection]

it should also be noted that node already supports import()

which version? or it needs the flag? All I am saying is that on the Web dynamic import(...) is the only way to bring in ESM world from a non ESM script.

It looks like node here already decided to break that Web contract.

[jkrems]

It looks like node here already decided to break that Web contract.

In what way? In node the only way to import ESM is via import from 'x', import('x'), and entry point. That seems to match the web contract?

P.S.: Support for dynamic import is only in node nightly and did require additional flags until very recently.

[WebReflection]

@jkrems on the Web you cannot import ... from a <script>, you can only import ... from a <script type=module>, either as file or as content.

However, you can always import(dynamic) from both <script> and <script type=module> and the dynamic import grants ESM as parse goal. Dynamic import is the only way to opt in ESM within a script executed in a non ESM goal.

Using import(file) to load CJS is misaligned with what the Web does already.

TL;DR import(...) on Web is the equivalent of --mode=esm or .mjs for current Node.

Maybe we could clarify this difference, if needed to exist, somewhere?

[bmeck]

Using import(file) to load CJS is misaligned with what the Web does already.

Would you say using import(file) to load WASM is misaligned? I think the problem is that Abstract Module Records can refer to any Module format that is supported. I put a non goal of

Interoperability of Module formats with environments that do not support Module formats that Node seeks to support

because there may be Module formats that Node and the browser end up supporting that the other does not. Should we remove that non-goal and add something else?

[jkrems]

Using import(file) to load CJS is misaligned with what the Web does already.

Well, importing any kind of non-ESM using any kind of import doesn't work on the web right now. But it will be the only way to support native modules for example (.node files). I don't think it will possible for us to not support module types that don't exist on the web longer term.

[WebReflection]

Would you say using import(file) to load WASM is misaligned?

you are comparing apple to oranges.
If you import a JavaScript file with console.log(this) it will log undefined. That file will be handled as ESM, never as regular script. The Web has two kind of scripts, like Node does. The sloppy one, which is the equivalent of CJS, and the strict ESM one.

import(JS) always grant the ESM one on web, never the sloppy one.

will be the only way to support native modules for example (.node files)

that's OK, there's no ambiguity or ESM to enforce in .node or .wasm or .json, I am talking about sloppy VS strict, CJS vs ESM.

We can discuss forever if it makes sense or not, all I am saying is that current nightly behavior is not congruent with the Web and we should probably declare the difference somewhere and also eventually agree it's a non goal to have 1:1 import(ESM) when it comes to same MIME.

[bmeck]

@WebReflection

import(JS)

By your definition what makes it JS instead of WASM.

[WebReflection]

this is a live demo of the equivalent of a sloppy/CJS that import(jsfile) with the exact same mime of the initial script that is not ESM but that grants ESM ... which part is not clear?

<!doctype html>
<script src="sloppy.js"><!-- not a module --></script>

// sloppy.js ... it uses import for a js file, same MIME
// import(...) is the disambiguation to bring in ESM
// when the MIME is text/javascript (or others)
import('./esm.js').then(module => {
  console.log(module.default);
});

// esm.js
import random from './random.js';
export default random;

// random.js
export default Math.random();

[bmeck]

@WebReflection What is unclear is the mechanism you are asking Node to use to determine which format a file is in when encountering your file. Your example is using content-type to determine the format of the dependency. I presume you intend to use file extension to determine the format of the dependency in Node. Node currently uses .js for CJS though, so another mechanism of disambiguation is needed to inform Node that the resolved file is ESM not CJS. The browser isn't using the specifier but another mechanism to determine format, same with Node. We are trying to understand what your mechanism is intending to be.

[TimothyGu]

@WebReflection I feel you are comparing apples to oranges. import() itself provides no contract how the loaded file is going to be executed. In this view, a Node.js CJS script (which is not ESM) is no different from WASM (which is also not ESM).

Whether the script is executed sloppily or not is an implementation detail.

[WebReflection]

Your example is using content-type to determine the format of the dependency.

no, sloppy.js is application/javasript and so is esm.js. Same MIME, import(...) grants to execute the same MIME with goal ESM.

import(...) is the disambiguation. If you'd append a script node then you'd need to specify type=module but that's not the case with import(file) because type=module is implicit.

import() itself provides no contract how the loaded file is going to be executed.

I've just explained this is not true. import(fs) grants type=module for js files.

Same Nodejs has CJS and ESM that could be on .js extension, Web has non modules and modules.

The Web has also the same MIME, and import(dynamic) resolves that mime as ESM

[TimothyGu]

@WebReflection

Same Nodejs has CJS and ESM that could be on .js extension, Web has non modules and modules.

CJS is different from web's non-module. Do you disagree?

[WebReflection]

CJS is different from web's non-module. Do you disagree?

CJS is a sloppy, non ESM, program. It is strict only if opted in.

// this is spider.js
with({greatPowers: 'comes great responsibility'})
  console.log(greatPowers);

Now go in node and require('./spider') to read the sentence. in this regard, CJS is like any sloppy JavaScript on the Web.

[TimothyGu]

CJS is a sloppy, non ESM, program.

What I see is that you have a different definition of CJS than most of us I (and @bmeck) do.

My definition of CJS:

• A module
• optionally A sloppy script

Your definition of CJS:

• A sloppy script (unless opted into strict mode)
• optionally A module

Am I correct in this description of your definition of CJS?

[WebReflection]

Am I correct in this description of your definition of CJS?

it's one point only to me: a sloppy module

point here is that the same extension disambiguation could be provided by dynamic import same exact way it does already on the Web.

Then again, I am saying that static import and dynamic import(...) are two different beasts and if we want to stick with browsers compat, we either explicitly say import('file.js') does not grant ESM parsing under non goals, or we change current dynamic import if we're still in time to make it the universal disambiguation to opt in ESM.

Either ways work for me (I lie, I prefer the second option: the opt-in), but ignoring it will bite someone at some point. Just my 2 cents. No intention to discuss this further 'cause I think we all perfectly understood each other.

[TimothyGu]

it's one point only to me: a sloppy module

No. You seem to value the sloppiness over the moduleness (i.e., importability) of CJS. And I don't think it's right.

I am saying that static import and dynamic import are two different beasts

Browser folks and TC39 say no.

ignoring it will bite someone at some point

Unfortunately ESM semantics can be pretty different from CJS semantics people are used to, either because they have been writing CJS or they have been using Babel's 'ESM', so this kind of issues biting someone is unavoidable. I don't think we should try to be perfect and provide a solution that will bite no one, because that does not exist. Actually it does, and it's called CJS. Oh wait, never mind.

[WebReflection]

Browser folks and TC39 say no.

can we please link sources to these statements? As example, here's one.

import() is proposed to work in both scripts and modules. This gives script code an easy asynchronous entry point into the module world, allowing it to start running module code.

That's because:

• static import means the code is already executed as ESM. The disambiguation of the parsing goal already happened
• dynamic import(...) can be executed in sloppy as well as in ESM. The disambiguation of the loaded file will be implicitly performed by the import(...) call and the file, if JavaScript, loaded as ESM.

We can keep ignoring this difference, but saying that those are the same is not very wise, IMO.

* worth mentioning that for browsers, module world is only ESM (hence strict) so if we want to keep this compatibility, or even if we don't, we might want to clarify in either goals or non goals this point. This is my opinion, you can disagree, it's OK.

[robpalme]

Maybe re-title the section from "Direction" to "Current Direction" if we're emphasizing it may change?

…

On Tue, 20 Feb 2018, 18:13 Bradley Meck, ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In GOALS.md <#23 (comment)>: > +9. Modification of existing `require` behavior + * Modification of implementation details is allowed only if it would be backwards compatible + +# Goals that are not expected for the first iteration + +1. 100% stable Loader APIs + * Any Loader APIs shipped must have a forward compatible approach towards their usage, such as providing a feature dection mechanism or versioned API. +2. Treatment of `.js` file extension as ESM by default +3. Support for the following URL schemes: `data:`, `blob:`, and `https:` + +# Direction + +* Build upon the existing work in Node that has designs around using `.mjs` +* Enable usage of `.js` for ESM through compatible means of out of band data +* Build upon the existing Loader hooks to aid usability + * Creation of in memory Module records @jdalton <https://github.com/jdalton> we can replace the status quo, but this section is basically documenting the status quo. The intent of this section is to allow progress to continue and not completely halt all development of ESM in Node while this group works. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGni9SaKMgRpHf7hUftokzyuUq7N2CYxks5tWwtSgaJpZM4R-08k> .

[bmeck]

@robpalme done, though this doesn't really reflect that it would be hard to change direction it seems fine.

[WebReflection]

FWIW, from this comment on, I share the exact same opinion/concerns of @jdalton .

If the direction is set in stones and unchangeable, I don't see any value in having this group 'cause there's nothing most of us can do, or better, nothing would be happy to do.

I'm not the best candidate for English specs wording, but if this document is meant to represent the foundation of the group, let's please try to not lock it into a direction majority of people here don't really like.

Thanks.

[giltayar]

As a balance, while I am respectful of the opinions of @jdalton and @WebReflection, I want to advocate @bmeck's (and probably others) way—let's take what we have and make it better.

I believe the two proposals currently on the table, the "esm" mode and loader hooks, will enable us to do exactly that: move forward while making everyone happy. Let's not throw away all the work that happened after literally years of discussion, and restart those discussions again.

Instead, let's take what we have, and try to figure out how to make the opponents of the current direction happy. Can we take what we have today, tweak it with things like esm mode, and have everybody satisfied with the result? I believe we can.

My concern is that if we throw away all the current hard work, and start discussing ESM from scratch, we will just be regurgitating and repeating the discussions people already had. Yes, we might arrive at different conclusions, but it will again take years.

Instead, let's take what we have, and figure out ways to resolve the problems that have surfaced and will surface.

Suggestion

@WebReflection and @jdalton: can you (and others in this group) add a "Concerns" section which enumerates the problems that you have with the current direction? That way we can continue building on the work already done, and addressing your concerns with it.

[WebReflection]

Can we take what we have today, tweak it with things like esm mode, and have everybody satisfied with the result? I believe we can.

me too, or I wouldn't be here. My point wasn't to throw away everything, rather to not keep doing everything around the .mjs direction which is the reason this group exists.

enumerates the problems that you have with the current direction?

It's a matter of mindset. If people writing the foundation believe .mjs is the future, instead of focusing on offering a solution that brings exact same future to .js too, we're stuck again and the will to contribute anyhow fades away.

Not sure that needs a counter section.

[giltayar]

@WebReflection - everybody wanted .js, but the reasons were there against it (the problem of figuring out what the parse goal of the file is), and the .mjs solution was the one chosen.

But now there is a PR that "returns" .js, but with an out of band indication that is per-directory (esm mode). Wouldn't that be the kind of tweaks I was talking about—that solves the real problem of a whole community that is "tied" to the .js extension?

[WebReflection]

I know there is an ESM mode and I'm happy. All I'm saying is that the foundation should be willing to move forward both cases instead of promoting .mjs as the solution with a mode as workaround.

Again, I just agree with @jdalton and I'd like to know we're here to always keep both directions in mind.

What will be the future, let users/adoption decide that.

Thanks.

[bmeck]

@WebReflection we can work on wording and promoting them as equals if/when we land that PR :). That seems like something that should probably be done since it is a major change to the state of things.

[bmeck]

people mentioned that some of these goals were leaking implementation detail expectations at the meeting, if we could isolate though and list them again I would like to try and remove implementation details from goals.

[MylesBorins]

This document was drafted before we had started work on use cases and features. As such I don't believe it is an accurate reflection of the current state of the working group.

@bmeck are you open to closing this?

[bmeck]

@MylesBorins seems fine since we are going back to use cases but we need to revisit this sometime in the future.