Semantics of this feature in Node.js

[littledan]

Note: The semantics of this proposal in Node.js would be determined by Node collaborators and the Node Modules Team, not in this repository. This issue is purely for requirements-gathering/brainstorming.

A lot of the discussion in the issues seems to relate to how this feature would integrate into non-Web environments. For concreteness, I'm going to talk about how this might integrate into Node.js, since I know slightly more about it than other non-Web environments (but I am no Node expert). I see two general paths for the interpretation. (Note, these are not the only possible paths, they're just two that I thought of to initiate discussion)

Option A: Maximizing for similarity with the web

If we want to be maximally compatible with the web -- that is, code written for Node.js would work on the Web without a build step to handle this aspect of semantics -- then we could simply use the logic in #24, but with s/MIME type/file extension (and possibly more information in package.json)/. The file extension used here would be after some resolution is done, as described in #4, so it may not be what's textually included in source. This would mean that importing JSON modules would require type: "json" to be textually in JS source that's used in Node.js, which differs from traditional ES6 module -> CJS transforms (which of course didn't have this syntax, but JSON modules were present anyway).

Option B: Maximizing for terseness/non-redundancy

On the other hand, we could make type: optional for non-JS all module types in Node.js. The semantics would be based on the template of Option A, but with the following change: if no type: is provided, then there is no check done, and processing is based just on the file extension (and possibly more information in package.json). This would mean that a build step is expected to add the with type: "json" or whatever else when building for the web.

How this would interact with other alternatives for where to put the attributes

If the attributes are put in an out-of-band file, or in the module specifier, or in a single string, Options A and B are still both available. They make different tradeoffs about web compatibility vs lack of redundancy. This proposal would permit Node.js and other environments to make this decision themselves, regardless of the choice of format for where to put the metadata.

[ljharb]

node has no need to use this type information at all; it would have to be optional for everything.

[littledan]

@ljharb Are you saying you agree with Option B, or do you have concerns with it? Under Option B, the type is optional, though if it's provided, it's checked for.

[ljharb]

Option B says optional for non-JS types; in node it’d be optional for every type.

[littledan]

Heh, the idea is that it's optional for non-JS types because of course it's just not provided for JS types... so yes, it'd be optional for all types.

It sounds like you're speaking on behalf of Node about what its semantics would be. Has the Node Modules team made a decision about this yet?

[littledan]

I've edited the original post to make the clarification.

[ljharb]

To clarify, I’m not speaking on behalf of node or the modules group; however, i can’t imagine that the UX tax of providing a type inline would gain consensus in either venue.

[littledan]

Is Option B acceptable to you, in your personal opinion about developer UX (modulo the question of how unknown types are processed)?

[ljharb]

The concerns motivating this proposal don’t exist in node, so if the syntax exists in the language, option B seems like the only non-disruptive way it could work (since compatible web code still needs to be able to work in node)

[bmeck]

I'd leave this to the node and the modules WG rather than attempting to state only a few possible options.

[littledan]

Yes, I definitely didn't mean that these are the only two options, and am supportive of this being decided by the Node Modules Team. I wanted to start the discussion, though. You can see that I've also filed issues about the web semantics, even though those would also happen in web standards bodies.

[bmeck]

@littledan I've added this to the modules WG. I'm just not comfortable speaking on behalf of the WG as neither of those options seem likely in personal viewpoint.

[jkrems]

To add to the node use case: There have been discussions around supporting https: module loading in node, either built-in or as a relatively common loader. So I'm personally not convinced that node is fundamentally different from the web here. The same kind of security concerns could apply in the future and making it optional now could be an issue then.