How are the module attributes interpreted across host environments?

[littledan]

Note: The module attributes proposal would not require or recommend that hosts use any particular interpretation of the attributes. Some people in the JS community have a goal of non-Web environments working towards partial Web-compatibility, but such efforts lie outside of the scope of this proposal. This issue exists for brainstorming and requirements gathering that may feed back into the module attributes proposal, but not to make any sort of requirement or recommendation for JS environments.

The ECMAScript specification leaves resolution of module specifiers up to the host environment, e.g., HTML or Node.js. Probably we'd do the same for this proposal. At the same time, there's a broad effort to define similar semantics across many embedding environments. For one example, JSON modules make just as much sense in HTML and Node.js, even if they would have some host-specific semantics (e.g., checking the MIME type on the web). How should we coordinate to build compatibility here?

I want to suggest that, specifically for module types, we could have the logic to dispatch on certain type strings (initially, just JSON) and give them semantics in ECMA-262, or say "no interpretation" and fall back to the host. This would be invoked after the MIME type is checked. There's more details to work out when writing the spec to verify that it's a viable layering, though.

(Edit: Added the following paragraph to replace the previous one)

I want to suggest that the host be responsible for handling module attributes, and may use facilities provided by ECMA-262 to handle certain module types, for example JSON modules. It's still to be determined whether non-Web hosts would want to require a type: declaration the way it seems like the Web would.

Would non-web hosts still require with type: "json", or would they be comfortable relying on the file extension? Would tooling end up adding with type: "json"? My personal preference at this point is to require the author to include this in all cases, for maximum consistency/compatibility across environments, but this is a tradeoff for ergonomics and incremental upgrade. I'd be interested in hearing your thoughts.

[devsnek]

With the example of type: json, in many systems, all the resources being loaded are already trusted, so such a type: json thing is kind of useless. In the case of systems like node, it could also, depending on how it were specified, block the ability of loaders to replace modules for polyfilling/apm/etc. This is why I kind of prefer the out-of-band approach. In this example, HTML has a legitimate problem here, but it isn't inherent to js in general.

In the most general sense, an important field on one host may not be known to another host. That other host also therefore doesn't know if it should ignore the field or throw because it doesn't understand the field.

[littledan]

I am not a Node collaborator and I really can't speak for them, but I wanted to mention some points of context from discussions with Node collaborators that make me suspect that we can't yet conclude that Node will not have a use for this kind of feature.

You explained in #4 that the interpretation of modules in Node is based on the file extension after remapping. So type: "json" may still be somewhat meaningful, though the priority may be lower if you trust everything.

My understanding is that there's a diversity of views within the Node.js community about how to view security boundaries, and in particular, interest from some people in reducing the amount of trust one module has for another. I believe there has not been a strong conclusion that type: "json" would not be needed (and this is why JSON modules have been re-flagged).

[devsnek]

@littledan definitely. i'm not trying to say node will go a certain way in the future, more just using its current behaviour as an example of problems we still have to think about.

[littledan]

To further discuss the semantics in the Web and Node.js, I filed issues #24 and #25. I want to emphasize that, although I'd be in favor of working to reach a higher level of compatibility across environments, I don't expect this proposal to force any host environment's hand in how any of the options are interpreted. I don't think the decision of where to put the metadata really relates to how similar the different host environments' semantics will be; if you have concerns otherwise, let's talk them over.

[littledan]

I've thought about some kinds of "cross-environment module attributes registry", but it's not clear what that would mean normatively, or how it would be managed. The big normative tool we have in TC39 is the JavaScript specification, managed by committee consensus, so that's what I think we should build on for now. The spec may require things of environments, even if it doesn't algorithmically specify them.

The expectation here is, some module attributes will be defined by ECMA-262, and others by environments. We can carve out a strong interoperable subset by defining as much as makes sense in the JS spec. The current spec draft defines the following:

• There's a type attribute, which acts as a check, not as part of the cache key
• type: "json" is defined (module per-environment checks, e.g., for MIME type or file extension) as a single default export which is the JSON.parse of some environment-provided string

I think we could collaborate as a committee to grow this over time, both the set of attributes recognized and the types.

Cross-environment compatibility was a widely held concern around module attributes, so I think that the approach here should be considered part of what we'd be asking for Stage 2 consensus on (at least as a starting point).

[xtuc]

There's a bigger discussion about attributes interpration across hosts, but for the type attribute the semantics got restricted wich makes the interpration more consistent across hosts.