Reference for stage-3 import-attributes #33856
Conversation
github-actions
bot
added
Content:JS
![github-actions[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
files/en-us/web/javascript/reference/statements/import/with/index.md
Outdated
Show resolved
Hide resolved
files/en-us/web/javascript/reference/statements/import/with/index.md
Outdated
Show resolved
Hide resolved
|
Preview URLs
External URLs (4)URL:
(comment last updated: 2024-05-31 17:39:52) |
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
| If your file is not run as a module (if it's referenced in an HTML file, the script tag must have `type="module"`), you will not be able to use static import declarations, but the asynchronous dynamic import syntax will always be available, allowing you to import modules into non-module environments. | ||
| If your file is not run as a module (if it's referenced in an HTML file, the script tag must have `type="module"`), you will not be able to use static import declarations. On the other hand, the asynchronous dynamic import syntax is always available, allowing you to import modules into non-module environments. | ||
|
|
||
| The `options` parameter allows different kinds of import options. For example, [import attributes](/en-US/docs/Web/JavaScript/Reference/Statements/import/with): |
There was a problem hiding this comment.
While options is designed to support future extensions, currently it only supports import attributes.
There was a problem hiding this comment.
Yes. I'm trying to be future-proof here by not implying that it's only designed for one specific feature. It's the same wording as for example error cause.
| @@ -40,6 +40,10 @@ import "module-name"; | |||
| - `aliasN` | |||
| - : Names that will refer to the named imports. Must be a valid JavaScript identifier. | |||
|
|
|||
| The import statement may also be followed by a series of modifiers after the `"module-name"`. They include: | |||
|
|
|||
There was a problem hiding this comment.
Also here, I would just say that it can be followed by a set of import attributes rather than "a lost of modifiers, one of which is import attributes"
There was a problem hiding this comment.
Part of the reason was that this doc was written when other syntaxes were being proposed (when source phase import wasn't using this syntax, IIRC). But yes here it sounds more reasonable to stick with what we have at the moment.
| {"name":"John"} | ||
| ``` | ||
|
|
||
| Modules are identified and parsed only according to their served [MIME type](/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types) — the file extension in the URL cannot be used to identify a file's type. In this case, the MIME type is `application/json`, which tells the host browser that the file is JSON and must be parsed as JSON. If, for some reason (e.g. the server is hijacked or bogus), the MIME type in the server response is set to `text/javascript` (for JavaScript source), then the file would be parsed and executed as code. If the "JSON" file actually contains malicious code, the `import` declaration would unintentionally execute external code, posing a serious security threat. |
|
|
||
| Instead, you must provide an attribute to tell the host that this file must contain JSON. To validate the module's type (via MIME type), you use the attribute key called `type`. To validate that the module is a JSON module, the value is `"json"`. | ||
|
|
||
| > **Note:** The actual attribute value does not correspond directly to the MIME type. It's separately specified by the [HTML specification](https://html.spec.whatwg.org/multipage/webappapis.html#module-type-allowed). |
There was a problem hiding this comment.
| > **Note:** The actual attribute value does not correspond directly to the MIME type. It's separately specified by the [HTML specification](https://html.spec.whatwg.org/multipage/webappapis.html#module-type-allowed). | |
| > **Note:** The actual `type` attribute value does not correspond directly to the MIME type. It's separately specified by the [HTML specification](https://html.spec.whatwg.org/multipage/webappapis.html#module-type-allowed). |
| import data from "https://example.com/data.json" with { type: "json" }; | ||
| ``` | ||
|
|
||
| This particular attribute does _not_ change how the module is interpreted. The host already knows to parse the module as JSON given the MIME type. It only uses the attribute to do _after-the-fact_ checking that the `data.json` module is, in fact, a JSON module. For example, if the response header changes to `Content-Type: text/javascript` instead, the program will fail: |
There was a problem hiding this comment.
This is nuance, but the attribute does change something: the browser will pass a different Accept header in the request to tell the server it's expecting JSON.
There was a problem hiding this comment.
It changes the fetching process but not the parsing/evaluation process, right? I'm trying to say that you cannot use type: "json" on a JS file and expect the JS to be magically parsed as JSON (which might work). But yes I will add this.
Fixes #29572.
@nicolo-ribaudo Please let me know if the current text looks correct and complete