You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 25, 2026. It is now read-only.
Forgive me if this is a naive question: Why not just indicate that a module is a non-executable and use mime-type to determine format. Something maybe like:
import$foofrom'foo.json'// import$ as a new keyword
or
importfoofrom'foo.json'!// ! as the non-executable operator
or
importfooas'foo.json'// 'as' being a new keyword for use with import
This would work for a vast majority of cases where one uses a IANA registered media type (or perhaps even one derived from them subject to community consensus). The browser/engine can maintain a mapping or query the media type.
Consider another contrived scenario to illustrate the loss of flexibility: Say in the future, browsers had YAML and JSON parsers built in to the browser. An assertion to JSON would lock in a developer and if the module provider changed over to YAML this would lead to an error, even-though the parsed data might be the same.
I am not challenging the proposal itself, since I can see legitimate reasons to assert a format, mime-type, hashes etc. But why force a developer to add this extra code when a single token might do the job more often than not, leaving the code more readable and a few bytes lighter.
Forgive me if this is a naive question: Why not just indicate that a module is a non-executable and use mime-type to determine format. Something maybe like:
or
or
This would work for a vast majority of cases where one uses a IANA registered media type (or perhaps even one derived from them subject to community consensus). The browser/engine can maintain a mapping or query the media type.
Consider another contrived scenario to illustrate the loss of flexibility: Say in the future, browsers had YAML and JSON parsers built in to the browser. An assertion to JSON would lock in a developer and if the module provider changed over to YAML this would lead to an error, even-though the parsed data might be the same.
I am not challenging the proposal itself, since I can see legitimate reasons to assert a format, mime-type, hashes etc. But why force a developer to add this extra code when a single token might do the job more often than not, leaving the code more readable and a few bytes lighter.