├── .editorconfig ├── .gitattributes ├── .github └── workflows │ └── build.yml ├── .gitignore ├── .npmrc ├── .nvmrc ├── LICENSE ├── README.md ├── content-type-vs-file-extension.md ├── index.html ├── package.json ├── spec.emu └── tag-security-and-privacy.md /.editorconfig: -------------------------------------------------------------------------------- 1 | root = true 2 | 3 | [*] 4 | charset = utf-8 5 | indent_style = tab 6 | end_of_line = lf 7 | insert_final_newline = true 8 | trim_trailing_whitespace = true 9 | 10 | [{README.md,package.json,spec.html,.travis.yml}] 11 | indent_style = space 12 | indent_size = 2 13 | -------------------------------------------------------------------------------- /.gitattributes: -------------------------------------------------------------------------------- 1 | # Automatically normalize line endings for all text-based files 2 | * text=auto 3 | 4 | index.html -diff merge=ours 5 | spec.js -diff merge=ours 6 | spec.css -diff merge=ours 7 | -------------------------------------------------------------------------------- /.github/workflows/build.yml: -------------------------------------------------------------------------------- 1 | name: Deploy spec 2 | 3 | on: [push] 4 | 5 | jobs: 6 | build: 7 | runs-on: ubuntu-latest 8 | 9 | steps: 10 | - uses: actions/checkout@v2 11 | - uses: actions/setup-node@v1 12 | with: 13 | node-version: '12.x' 14 | - run: npm install 15 | - run: npm run build 16 | - name: commit changes 17 | uses: elstudio/actions-js-build/commit@v3 18 | with: 19 | commitMessage: "fixup: [spec] `npm run build`" 20 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | dist 2 | 3 | # Installed npm modules 4 | package-lock.json 5 | node_modules 6 | 7 | # Folder view configuration files 8 | .DS_Store 9 | Desktop.ini 10 | 11 | # Thumbnail cache files 12 | ._* 13 | Thumbs.db 14 | 15 | # Files that might appear on external disks 16 | .Spotlight-V100 17 | .Trashes 18 | -------------------------------------------------------------------------------- /.npmrc: -------------------------------------------------------------------------------- 1 | package-lock=false 2 | -------------------------------------------------------------------------------- /.nvmrc: -------------------------------------------------------------------------------- 1 | 12 2 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "{}" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright {yyyy} {name of copyright owner} 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | 203 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Import Attributes 2 | 3 | Champions: Sven Sauleau ([@xtuc](https://github.com/xtuc)), Daniel Ehrenberg ([@littledan](https://github.com/littledan)), Myles Borins ([@MylesBorins](https://github.com/MylesBorins)), Dan Clark ([@dandclark](https://github.com/dandclark)), and Nicolò Ribaudo ([@nicolo-ribaudo](https://github.com/nicolo-ribaudo)). 4 | 5 | Status: Stage 4 6 | 7 | > ⚠️ The specification in this proposal might be out of date. [tc39/ecma262#3057](https://github.com/tc39/ecma262/pull/3057) is the latest version. 8 | > 9 | > Some of the changes present in the current specification have not been presented to committee yet: [#142](https://github.com/tc39/proposal-import-attributes/issues/142) 10 | 11 | Please leave any feedback you have in the [issues](http://github.com/tc39/proposal-import-attributes/issues)! 12 | 13 | ## Synopsis 14 | 15 | The Import Attributes proposal, formerly known as Import Assertions, adds an inline syntax for module import statements to pass on more information alongside the module specifier. The initial application for such attributes will be to support additional types of modules in a common way across JavaScript environments, starting with [JSON modules](http://github.com/tc39/proposal-json-modules). 16 | 17 | The syntax will be as follows (shown here is the proposed method for importing a JSON module): 18 | ```js 19 | import json from "./foo.json" with { type: "json" }; 20 | import("foo.json", { with: { type: "json" } }); 21 | ``` 22 | 23 | The specification of JSON modules was originally part of this proposal, but it was [resolved](https://github.com/tc39/notes/blob/master/meetings/2020-07/july-21.md#import-conditions-for-stage-3) during the July 2020 meeting to split JSON modules out into a [separate Stage 3 proposal](http://github.com/tc39/proposal-json-modules). 24 | 25 | ## Motivation 26 | 27 | Standards-track JSON ES modules were [proposed](https://github.com/w3c/webcomponents/issues/770) to allow JavaScript modules to easily import JSON data files, similarly to how they are supported in many nonstandard JavaScript module systems. This idea quickly got broad support from web developers and browsers, and was merged into HTML, with an implementation for V8/Chromium created by Microsoft. 28 | 29 | However, in [an issue](https://github.com/w3c/webcomponents/issues/839), Ryosuke Niwa (Apple) and Anne van Kesteren (Mozilla) proposed that security would be improved if some syntactic marker were required when importing JSON modules and similar module types which cannot execute code, to prevent a scenario where the responding server unexpectedly provides a different MIME type, causing code to be unexpectedly executed. The solution was to somehow indicate that a module was JSON, or in general, not to be executed, somewhere in addition to the MIME type. 30 | 31 | Some developers have the intuition that the file extension could be used to determine the module type, as it is in many existing non-standard module systems. However, it's a deep web architectural principle that the suffix of the URL (which you might think of as the "file extension" outside of the web) does not lead to semantics of how the page is interpreted. In practice, on the web, there is a widespread [mismatch between file extension and the HTTP Content Type header](content-type-vs-file-extension.md). All of this sums up to it being infeasible to depend on file extensions/suffixes included in the module specifier to be the basis for this checking. 32 | 33 | There are other possible pieces of metadata which could be associated with modules, see [#8](https://github.com/tc39/proposal-import-attributes/issues/8) and [tc39/proposal-import-reflection#18](https://github.com/tc39/proposal-import-reflection/issues/18) for further discussion. 34 | 35 | Proposed ES module types that are blocked by this security concern, in addition to JSON modules, include [CSS modules](https://github.com/whatwg/html/pull/4898) and potentially [HTML modules](https://github.com/whatwg/html/pull/4505) if the HTML module proposal is restricted to [not allow script](https://github.com/w3c/webcomponents/issues/805). 36 | 37 | ## Rationale 38 | 39 | There are three places where this data could be provided: 40 | - As part of the module specifier (e.g., as a pseudo-scheme) 41 | - Challenges: Adds complexity to URLs or other module specifier syntaxes, and risks being confusing to developers (further discussion: [#11](https://github.com/tc39/proposal-import-attributes/issues/11)) 42 | - webpack supports this sort of construct ([docs](https://webpack.js.org/concepts/loaders/#inline)). 43 | - Demand from users for similar behavior in Parcel, with pushback from some maintainers ([#3477](https://github.com/parcel-bundler/parcel/issues/3477)) 44 | - Separately, out of band (e.g., a separate resource file) 45 | - Challenges: How to load that resource file; what should the format be; unergonomic to have to jump between files during development (further discussion: [#13](https://github.com/tc39/proposal-import-attributes/issues/13)) 46 | - In the JavaScript source text 47 | - Challenges: Requires a change at the JavaScript language level (this proposal) 48 | 49 | This proposal pursues the third option, as we expect it to lead to the best developer experience, and are hopeful that language design/standardization issues can be resolved. 50 | 51 | ## Proposed syntax 52 | 53 | Import attributes have to be made available in several different contexts. They use a key-value syntax is used preceded by the `with` keyword, with the key `type` used as an example indicating the module type. Such key-value syntax can be used in various different contexts. 54 | 55 | ### import statements 56 | 57 | The ImportDeclaration would allow any arbitrary attributes after the `with` keyword. 58 | 59 | For example, the `type` attribute could be used to indicate a module type, for example importing a JSON module with the following syntax. 60 | 61 | ```mjs 62 | import json from "./foo.json" with { type: "json" }; 63 | ``` 64 | 65 | The `with` syntax in the `ImportDeclaration` statement uses curly braces, for the following reasons (as discussed in [#5](https://github.com/tc39/proposal-import-attributes/issues/5)): 66 | - JavaScript developers are already used to the Object literal syntax and since it allows a trailing comma copy/pasting attributes will be easy. 67 | - it clearly indicates the end of the attributes list when splitting them across multiple lines. 68 | 69 | ### re-export statements 70 | 71 | Similar to import statements, the ExportDeclaration, when re-exporting from another module, would allow any arbitrary attributes after the `with` keyword. 72 | 73 | ```mjs 74 | export { val } from './foo.js' with { type: "javascript" }; 75 | ``` 76 | 77 | ### dynamic import() 78 | 79 | The `import()` pseudo-function would allow import attributes to be indicated in an options bag in the second argument. 80 | 81 | ```js 82 | import("foo.json", { with: { type: "json" } }) 83 | ``` 84 | 85 | The second parameter to `import()` is an options bag, with the only option currently defined to be `with`: the value here is an object containing the import attributes. There are other proposals for entries to put in the options bag: for example, the [Module Source Imports](https://github.com/tc39/proposal-import-reflection) proposal introduces a `phase` property. 86 | 87 | ### Integration of modules into environments 88 | 89 | Host environments (e.g., the Web platform, Node.js) often provide various different ways of loading modules. The analogous string could be passed through these ways of loading other kinds of modules. 90 | 91 | #### Worker instantiation 92 | 93 | ```js 94 | new Worker("foo.wasm", { type: "module", with: { type: "webassembly" } }); 95 | ``` 96 | 97 | Sidebar about WebAssembly module types and the web: it's still uncertain whether importing WebAssembly modules would need to be marked specially, or would be imported just like JavaScript. Further discussion in [#19](https://github.com/tc39/proposal-import-attributes/issues/19). 98 | 99 | #### HTML 100 | 101 | Although changes to HTML won't be specified by TC39, an idea here would be that each import attribute, preceded by `with`, becomes an HTML attribute which could be used in script tags. 102 | 103 | ```html 104 | 105 | ``` 106 | 107 | (See the caveat about WebAssembly above.) 108 | 109 | #### WebAssembly 110 | 111 | In the context of the [WebAssembly/ESM integration proposal](https://github.com/webassembly/esm-integration): for imports of other module types from within a WebAssembly module, this proposal would introduce a new custom section (named `importattributes`) that will annotate with attributes each imported module (which is listed in the import section). 112 | 113 | ## Proposed semantics and interoperability 114 | 115 | This proposal does not specify behavior for any particular attribute key or value. The [JSON modules proposal](https://github.com/tc39/proposal-json-modules) will specify that `type: "json"` must be interpreted as a JSON module, and will specify common semantics for doing so. It is expected the `type` attribute will be leveraged to support additional module types in future TC39 proposals as well as by hosts. HTML and CSS modules are under consideration, and these may use similar explicit `type` syntax when imported. 116 | 117 | Attributes in addition than `type` may also be introduced for purposes not yet foreseen. 118 | 119 | JavaScript implementations are encouraged to reject attributes and type values which are not implemented in their environment (rather than ignoring them). This is to allow for maximal flexibility in the design space in the future--in particular, it enables new import attributes to be defined which change the interpretation of a module, without breaking backwards-compatibility. 120 | 121 | ## FAQ 122 | 123 | ### Why not out of band? 124 | 125 | Why not both? The champions of this proposal think that exploring both an in- and out of band solutions to various kinds of metadata. While we prefer in-band metadata for module types, we are happy to see the development of various out-of-band manifests of modules being proposed and implemented in certain JS environments: 126 | - [import maps](https://github.com/WICG/import-maps) to map module specifiers to URLs/paths 127 | - [Node.js policy files](https://nodejs.org/api/policy.html), e.g., to perform integrity checks on modules 128 | 129 | This proposal does not exclude out-of-band metadata being used for module types. And it definitely doesn't argue that all metadata should be in-band. For example, integrity hashes simply don't work in-band, both because module circularities make them impossible to calculate, and because of the need for a "cascading" update when a deep dependency changes. 130 | 131 | Out-of-band solutions face certain downsides; these are not necessarily fatal, but are interesting to take into account when considering the solution space and making tradeoffs: 132 | - **By-hand authoring experience**: While an in-band solution is somewhat verbose, it is also more straightforward for developers to adopt when writing code without much tooling. For smaller projects developers do not need to create an extra file by hand. 133 | - **Tooling complexity for large projects**: For large project with many dependencies, developers will not have to worry about creating a large manifest by compiling the metadata of all of their dependencies. Module authors will also not have to worry about shipping a manifest in order for consumers to be able to run their modules. 134 | - **Performance tradeoffs**: The experience in Node.js's experimental, out-of-band policy files is that they can carry significant startup cost, due to certain aspects of loading and parsing. 135 | 136 | ### How is common behavior ensured across JavaScript environments? 137 | 138 | A central goal of this proposal is to share as much syntax and behavior across JavaScript environments as possible. To the same end, we also [propose](https://github.com/tc39/proposal-json-modules) a standardization of JSON modules to the extent that this is possible (omitting just the contents of the redundant type check, which necessarily differs between environments, in addition to the pre-existing host-defined parts such as interpreting the module specifier and fetching the module). 139 | 140 | However, at the same time, behavior of modules in general, and the set of module types specifically, is expected to differ across JavaScript environments. For example, WebAssembly, HTML and CSS modules may not make sense in certain minimal embedded JavaScript environments. We hope that environments can experiment and collaborate where it makes sense for them. 141 | 142 | We see the management of compatibility issues across environments as similar, independent of whether metadata is held in-band or out-of-band. An out of band solution would also suffer from the risk of inconsistent implementation or support across host environments if some kind of coordination does not occur. 143 | 144 | The topic of attribute divergence is further discussed in [#34](https://github.com/tc39/proposal-import-attributes/issues/34). 145 | 146 | ### How would this proposal work with caching? 147 | 148 | Attributes are part of the module cache key and can affect how a module is loaded: the cache key is extended from _(referrer, specifier)_ to _(referrer, specifier, attributes)_. 149 | 150 | ### Why not use more terse syntax to indicate module types, like `import json from "./foo.json" as "json"`? 151 | 152 | Another option considered and not selected has been to use a single string as the attribute, indicating the type. This option is not selected due to its implication that any particular attribute is special; even though this proposal only specifies the `type` attribute, the intention is to be open to more attributes in the future. (discussion in [#12](https://github.com/tc39/proposal-import-attributes/issues/12)). 153 | 154 | ### Should more than just strings be supported as attribute values? 155 | 156 | We could permit import attributes to have more complex values than simply strings, for example: 157 | 158 | ```js 159 | import value from "module" with { attr: { key1: "value1", key2: [1, 2, 3] } }; 160 | ``` 161 | 162 | This would allow import attributes to scale to support a larger variety of metadata. 163 | 164 | We propose to omit this generalization in the initial proposal, as a key/value list of strings already affords significant flexibility to start, but we're open to a follow-on proposal providing this kind of generalization. 165 | 166 | ### What are you open to changing? When do we have to settle down on the details? 167 | 168 | We are planning to make descisions and reach consensus during specific stages of this proposal. Here's our plan. 169 | 170 |
171 | Original plan before Stage 2 and Stage 3 172 | 173 | #### Before stage 2 174 | 175 | We have achieved consensus on the following core decisions as part of Stage 2, including: 176 | 177 | - The attribute form; key-value or single string ([#12](https://github.com/tc39/proposal-import-attributes/issues/12)) 178 | 179 | ```mjs 180 | // Not selected 181 | import value from "module" as "json"; 182 | 183 | // Not selected 184 | import value from "module" with type: "json"; 185 | 186 | // Proposal that was approved from Stage 2 to Stage 3 the first time 187 | import value from "module" assert { type: "json" }; 188 | ``` 189 | 190 | #### Before stage 3 191 | 192 | After Stage 2 and before Stage 3, we're open to settling on some less core details, such as: 193 | 194 | - Considering alternatives for the `with`/`if`/`assert` keywords ([#3](https://github.com/tc39/proposal-import-attributes/issues/3)) 195 | 196 | ```mjs 197 | import value from "module" when { type: 'json' }; 198 | import value from "module" given { type: 'json' }; 199 | ``` 200 | 201 | - How dynamic import would accept import attributes: 202 | ```mjs 203 | import("foo.wasm", { with: { type: "webassembly" } }); 204 | ``` 205 | 206 | For consistency the `assert` key is used for both dynamic and static imports. 207 | 208 | An alternative would be to remove the `assert` nesting in the object: 209 | ```mjs 210 | import("foo.wasm", { type: "webassembly" }); 211 | ``` 212 | 213 | However, that's not possible with the `Worker` API since it already uses an object with a `type` key as the second parameter. Which would make the APIs inconsistent. 214 | 215 |
216 | 217 | #### Before Stage 4 218 | 219 | - The integration of import attributes into various host environments. 220 | - For example, in the Web Platform, how import attributes would be enabled when launching a worker (if that is supported in the initial version to be shipped on the Web) or included in a ` 4 | 5 | Import Attributes 6 | 
  7 |   title: Import Attributes
  8 |   status: proposal
  9 |   stage: 3
 10 |   location: https://github.com/tc39/proposal-import-attributes
 11 |   copyright: false
 12 |   contributors: Sven Sauleau, Myles Borins, Daniel Ehrenberg, Daniel Clark, Nicolò Ribaudo
 13 |
14 | 15 | 16 |

Import Attributes

17 |

See the explainer for information.

18 |

The relevant syntax changes are in the Import Calls and Imports sections.

19 | 20 | 21 |

This document might be out of date. Please refer to the tc39/ecma262#3057 preview for the latest version.

22 | 23 | 24 | 25 | 26 |

ECMAScript Language: Expressions

27 | 28 | 29 |

Left-Hand-Side Expressions

30 |

Syntax

31 | 32 | ImportCall[Yield, Await] : 33 | `import` `(` AssignmentExpression[+In, ?Yield, ?Await] `,`? `)` 34 | `import` `(` AssignmentExpression[+In, ?Yield, ?Await] `,` AssignmentExpression[+In, ?Yield, ?Await] `,`? `)` 35 | 36 | 37 | 38 |

Import Calls

39 | 40 | 41 |

Runtime Semantics: Evaluation

42 | 43 | ImportCall : `import` `(` AssignmentExpression `,`? `)` 44 | 45 | 1. Return ? EvaluateImportCall(|AssignmentExpression|). 46 | 47 | 48 | ImportCall : `import` `(` AssignmentExpression `,` AssignmentExpression `,`? `)` 49 | 50 | 1. Return ? EvaluateImportCall(the first |AssignmentExpression|, the second |AssignmentExpression|). 51 | 52 | 53 | ImportCall : `import` `(` AssignmentExpression `)` 54 | 55 | 1. Let _referrer_ be GetActiveScriptOrModule(). 56 | 1. If _referrer_ is *null*, set _referrer_ to the current Realm Record. 57 | 1. Let _argRef_ be ? Evaluation of |AssignmentExpression|. 58 | 1. Let _specifier_ be ? GetValue(_argRef_). 59 | 1. Let _promiseCapability_ be ! NewPromiseCapability(%Promise%). 60 | 1. Let _specifierString_ be Completion(ToString(_specifier_)). 61 | 1. IfAbruptRejectPromise(_specifierString_, _promiseCapability_). 62 | 1. Perform HostLoadImportedModule(_referrer_, _specifierString_, ~empty~, _promiseCapability_). 63 | 1. Return _promiseCapability_.[[Promise]]. 64 | 65 | 66 | 67 | 68 |

69 | 70 | EvaluateImportCall ( 71 | _specifierExpression_: a ParseNode, 72 | optional _optionsExpression_: a ParseNode 73 | ): either a normal completion containing a Promise or a throw completion 74 | 75 |

76 |
77 | 78 | 1. Let _referrer_ be GetActiveScriptOrModule(). 79 | 1. If _referrer_ is *null*, set _referrer_ to the current Realm Record. 80 | 1. Let _specifierRef_ be the result of evaluating _specifierExpression_. 81 | 1. Let _specifier_ be ? GetValue(_specifierRef_). 82 | 1. If _optionsExpression_ is present, then 83 | 1. Let _optionsRef_ be the result of evaluating _optionsExpression_. 84 | 1. Let _options_ be ? GetValue(_optionsRef_). 85 | 1. Else, 86 | 1. Let _options_ be *undefined*. 87 | 1. Let _promiseCapability_ be ! NewPromiseCapability(%Promise%). 88 | 1. Let _specifierString_ be Completion(ToString(_specifier_)). 89 | 1. IfAbruptRejectPromise(_specifierString_, _promiseCapability_). 90 | 1. Let _attributes_ be a new empty List. 91 | 1. If _options_ is not *undefined*, then 92 | 1. If Type(_options_) is not Object, then 93 | 1. Perform ! Call(_promiseCapability_.[[Reject]], *undefined*, « a newly created *TypeError* object »). 94 | 1. Return _promiseCapability_.[[Promise]]. 95 | 1. Let _attributesObj_ be Completion(Get(_options_, *"with"*)). 96 | 1. IfAbruptRejectPromise(_attributesObj_, _promiseCapability_). 97 | 1. If _attributesObj_ is not *undefined*, then 98 | 1. If Type(_attributesObj_) is not Object, then 99 | 1. Perform ! Call(_promiseCapability_.[[Reject]], *undefined*, « a newly created *TypeError* object »). 100 | 1. Return _promiseCapability_.[[Promise]]. 101 | 1. Let _entries_ be Completion(EnumerableOwnProperties(_attributesObj_, ~key+value~)). 102 | 1. IfAbruptRejectPromise(_entries_, _promiseCapability_). 103 | 1. For each _entry_ of _entries_, do 104 | 1. Let _key_ be ! Get(_entry_, *"0"*). 105 | 1. Let _value_ be ! Get(_entry_, *"1"*). 106 | 1. If Type(_value_) is not String, then 107 | 1. Perform ! Call(_promiseCapability_.[[Reject]], *undefined*, « a newly created *TypeError* object »). 108 | 1. Return _promiseCapability_.[[Promise]]. 109 | 1. Append the ImportAttribute Record { [[Key]]: _key_, [[Value]]: _value_ } to _attributes_. 110 | 1. If AllImportAttributesSupported(_attributes_) is *false*, then 111 | 1. Perform ! Call(_promiseCapability_.[[Reject]], *undefined*, « a newly created *TypeError* object »). 112 | 1. Return _promiseCapability_.[[Promise]]. 113 | 1. Sort _attributes_ according to the lexicographic order of their [[Key]] fields, treating the value of each such field as a sequence of UTF-16 code unit values. NOTE: This sorting is observable only in that hosts are prohibited from distinguishing among attributes by the order they occur in. 114 | 1. Let _moduleRequest_ be a new ModuleRequest Record { [[Specifier]]: _specifierString_, [[Attributes]]: _attributes_ }. 115 | 1. Perform HostLoadImportedModule(_referrer_, _moduleRequest_, ~empty~, _promiseCapability_). 116 | 1. Return _promiseCapability_.[[Promise]]. 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 |

ECMAScript Language: Scripts and Modules

125 | 126 | 127 |

Modules

128 | 129 | 130 |

Module Semantics

131 | 132 | 133 |

ModuleRequest and ImportAttribute Records

134 | 135 |

A ModuleRequest Record represents the request to import a module with given import attributes. It consists of the following fields:

136 | 137 | 138 | 139 | 140 | 143 | 146 | 149 | 150 | 151 | 154 | 157 | 160 | 161 | 162 | 165 | 168 | 171 | 172 | 173 |
141 | Field Name 142 | 144 | Value Type 145 | 147 | Meaning 148 |
152 | [[Specifier]] 153 | 155 | String 156 | 158 | The module specifier 159 |
163 | [[Attributes]] 164 | 166 | a List of ImportAttribute Records 167 | 169 | The import attributes 170 |
174 | 175 | 176 | In general, this proposal replaces places where module specifiers are passed around with ModuleRequest Records. For example, several syntax-directed operations, such as ModuleRequests produce Lists of ModuleRequest Records rather than Lists of Strings which are interpreted as module specifiers. Some algorithms like ImportEntries and ImportEntriesForModule pass around ModuleRequest Records rather than Strings, in a way which doesn't require any particular textual change. Additionally, record fields in Cyclic Module Records and Source Text Module Records which contained Lists of Strings are replaced by Lists of ModuleRequest Records, as indicated above. 177 | 178 |

A LoadedModuleRequest Record represents the request to import a module together with the resulting Module Record. It consists of the same fields defined in table , with the addition of [[Module]]:

179 | 180 | 181 | 182 | 185 | 188 | 191 | 192 | 193 | 196 | 199 | 202 | 203 | 204 | 207 | 210 | 213 | 214 | 215 | 218 | 221 | 224 | 225 |
183 | Field Name 184 | 186 | Value Type 187 | 189 | Meaning 190 |
194 | [[Specifier]] 195 | 197 | a String 198 | 200 | The module specifier 201 |
205 | [[Attributes]] 206 | 208 | a List of ImportAttribute Records 209 | 211 | The import attributes 212 |
216 | [[Module]] 217 | 219 | a Module Record 220 | 222 | The loaded module corresponding to this module request 223 |
226 | 227 | 228 |

An ImportAttribute Record consists of the following fields:

229 | 230 | 231 | 232 | 233 | 236 | 239 | 242 | 243 | 244 | 247 | 250 | 253 | 254 | 255 | 258 | 261 | 264 | 265 | 266 |
234 | Field Name 235 | 237 | Value Type 238 | 240 | Meaning 241 |
245 | [[Key]] 246 | 248 | String 249 | 251 | The attribute key 252 |
256 | [[Value]] 257 | 259 | String 260 | 262 | The attribute value 263 |
267 | 268 | 269 | 270 |

271 | 272 | ModuleRequestsEqual ( 273 | _left_: a ModuleRequest Record or a LoadedModuleRequest Record, 274 | _right_: a ModuleRequest Record or a LoadedModuleRequest Record, 275 | ): a Boolean 276 | 277 |

278 |
279 |
description
280 |
281 |
282 | 283 | 284 | 1. If _left_.[[Specifier]] is not _right_.[[Specifier]], return *false*. 285 | 1. Let _leftAttrs_ be _left_.[[Attributes]]. 286 | 1. Let _rightAttrs_ be _right_.[[Attributes]]. 287 | 1. Let _leftAttrsCount_ be the number of elements in _leftAttrs_. 288 | 1. Let _rightAttrsCount_ be the number of elements in _rightAttrs_. 289 | 1. If _leftAttrsCount_ ≠ _rightAttrsCount_, return *false*. 290 | 1. For each ImportAttribute Record _l_ of _leftAttrs_, do 291 | 1. Let _found_ be *false*. 292 | 1. For each ImportAttribute Record _r_ of _rightAttrs_, do 293 | 1. If _l_.[[Key]] is _r_.[[Key]], then 294 | 1. If _l_.[[Value]] is _r_.[[Value]], then 295 | 1. Assert: _found_ is *false*. 296 | 1. Set _found_ to *true*. 297 | 1. Else, 298 | 1. Return *false*. 299 | 1. If _found_ is *false*, return *false*. 300 | 1. Return *true*. 301 | 302 | 303 | 304 | 305 | 306 |

307 | Static Semantics: ModuleRequests ( ): a List of StringsModuleRequest Records 308 |

309 |
310 |
311 | Module : [empty] 312 | 313 | 1. Return a new empty List. 314 | 315 | ModuleItemList : ModuleItem 316 | 317 | 1. Return ModuleRequests of |ModuleItem|. 318 | 319 | ModuleItemList : ModuleItemList ModuleItem 320 | 321 | 1. Let _moduleNames__requests_ be ModuleRequests of |ModuleItemList|. 322 | 1. Let _additionalNames__additionalRequests_ be ModuleRequests of |ModuleItem|. 323 | 1. For each String _name_ of _additionalNames_, do 324 | 1. For each ModuleRequest Record _mr_ of _additionalRequests_, do 325 | 1. If _moduleNames__requests_ does not contain _name_ a ModuleRequest Record _mr2_ such that ModuleRequestsEqual(_mr_, _mr2_) is *true*, then 326 | 1. Append _name__mr_ to _moduleNames__requests_. 327 | 1. Return _moduleNames__requests_. 328 | 329 | ModuleItem : StatementListItem 330 | 331 | 1. Return a new empty List. 332 | 333 | 334 | ImportDeclaration : `import` ImportClause FromClause `;` 335 | 336 | 337 | 1. Return ModuleRequests of |FromClause|. 338 | 1. Let _specifier_ be SV of |FromClause|. 339 | 1. Return a List whose sole element is the ModuleRequest Record { [[Specifer]]: _specifier_, [[Attributes]]: « » }. 340 | 341 | 342 | ImportDeclaration : `import` ImportClause FromClause WithClause `;` 343 | 344 | 345 | 1. Let _specifier_ be the SV of |FromClause|. 346 | 1. Let _attributes_ be WithClauseToAttributes of |WithClause|. 347 | 1. Return a List whose sole element is the ModuleRequest Record { [[Specifer]]: _specifier_, [[Attributes]]: _attributes_ }. 348 | 349 | ImportDeclaration : `import` ModuleSpecifier `;` 350 | 351 | 1. Let _specifier_ be the SV of |ModuleSpecifier|. 352 | 1. Return a List whose sole element is the ModuleRequest Record { [[Specifer]]: _specifier_, [[Attributes]]: « » }. 353 | 354 | ImportDeclaration : `import` ModuleSpecifier WithClause `;` 355 | 356 | 1. Let _specifier_ be the SV of |ModuleSpecifier|. 357 | 1. Let _attributes_ be WithClauseToAttributes of |WithClause|. 358 | 1. Return a List whose sole element is the ModuleRequest Record { [[Specifer]]: _specifier_, [[Attributes]]: _attributes_ }. 359 | 360 | ModuleSpecifier : StringLiteral 361 | 362 | 1. Return a List whose sole element is the SV of |StringLiteral|. 363 | 364 | 365 | ExportDeclaration : `export` ExportFromClause FromClause `;` 366 | 367 | 368 | 1. Return ModuleRequests of |FromClause|. 369 | 1. Let _specifier_ be SV of |FromClause|. 370 | 1. Return a List whose sole element is the ModuleRequest Record { [[Specifer]]: _specifier_, [[Attributes]]: « » }. 371 | 372 | 373 | ExportDeclaration : `export` ExportFromClause FromClause WithClause `;` 374 | 375 | 376 | 1. Let _specifier_ be SV of |FromClause|. 377 | 1. Let _attributes_ be WithClauseToAttributes of |WithClause|. 378 | 1. Return a List whose sole element is the ModuleRequest Record { [[Specifer]]: _specifier_, [[Attributes]]: _attributes_ }. 379 | 380 | 381 | ExportDeclaration : 382 | `export` NamedExports `;` 383 | `export` VariableStatement 384 | `export` Declaration 385 | `export` `default` HoistableDeclaration 386 | `export` `default` ClassDeclaration 387 | `export` `default` AssignmentExpression `;` 388 | 389 | 390 | 1. Return a new empty List. 391 | 392 | 393 | 394 | 395 |

Cyclic Module Records

396 |

A Cyclic Module Record is used to represent information about a module that can participate in dependency cycles with other modules that are subclasses of the Cyclic Module Record type. Module Records that are not subclasses of the Cyclic Module Record type must not participate in dependency cycles with Source Text Module Records.

397 |

In addition to the fields defined in Cyclic Module Records have the additional fields listed in

398 | 399 | 400 | 401 | 404 | 407 | 410 | 411 | 412 | 415 | 416 | 417 | 418 | 419 | 422 | 423 | 424 | 425 | 426 | 429 | 430 | 431 | 432 | 433 | 436 | 437 | 438 | 439 | 440 | 443 | 446 | 449 | 450 | 451 | 454 | 457 | 460 | 461 | 462 | 465 | 466 | 467 | 468 | 469 | 472 | 473 | 474 | 475 | 476 | 479 | 480 | 481 | 482 | 483 | 486 | 487 | 488 | 489 | 490 | 493 | 494 | 495 | 496 | 497 | 500 | 501 | 502 | 503 |
402 | Field Name 403 | 405 | Value Type 406 | 408 | Meaning 409 |
413 | [[Status]] 414 |
420 | [[EvaluationError]] 421 |
427 | [[DFSIndex]] 428 |
434 | [[DFSAncestorIndex]] 435 |
441 | [[RequestedModules]] 442 | 444 | a List of StringsModuleRequest Records 445 | 447 | A List of all the |ModuleSpecifier| strings and import attributes used by the module represented by this record to request the importation of a module. The List is in source text occurrence order. 448 |
452 | [[LoadedModules]] 453 | 455 | a List of Records with fields [[Specifier]] (a String) and [[Module]] (a Module Record)LoadedModuleRequest Records 456 | 458 | A map from the specifier strings used by the module represented by this record to request the importation of a module with the relative attributes to the resolved Module Record. The list does not contain two different Records with the same [[Specifier]]([[Specifier]], [[Attributes]]) pair. 459 |
463 | [[CycleRoot]] 464 |
470 | [[HasTLA]] 471 |
477 | [[AsyncEvaluation]] 478 |
484 | [[TopLevelCapability]] 485 |
491 | [[AsyncParentModules]] 492 |
498 | [[PendingAsyncDependencies]] 499 |
504 | 505 | 506 | 507 |

508 | LoadRequestedModules ( 509 | optional _hostDefined_: anything, 510 | ): a Promise 511 |

512 |
513 |
for
514 |
a Cyclic Module Record _module_
515 | 516 |
description
517 |
518 |
519 | 520 | 521 |

522 | InnerModuleLoading ( 523 | _state_: a GraphLoadingState Record, 524 | _module_: a Module Record, 525 | ): ~unused~ 526 |

527 |
528 |
description
529 |
It is used by LoadRequestedModules to recursively perform the actual loading process for _module_'s dependency graph.
530 |
531 | 532 | 533 | 1. Assert: _state_.[[IsLoading]] is *true*. 534 | 1. If _module_ is a Cyclic Module Record, _module_.[[Status]] is ~new~, and _state_.[[Visited]] does not contain _module_, then 535 | 1. Append _module_ to _state_.[[Visited]]. 536 | 1. Let _requestedModulesCount_ be the number of elements in _module_.[[RequestedModules]]. 537 | 1. Set _state_.[[PendingModulesCount]] to _state_.[[PendingModulesCount]] + _requestedModulesCount_. 538 | 1. For each StringModuleRequest Record _request_ of _module_.[[RequestedModules]], do 539 | 1. If AllImportAttributesSupported(_request_.[[Attributes]]) is *false*, then 540 | 1. Let _error_ be ThrowCompletion(a newly created *SyntaxError* object). 541 | 1. Perform ContinueModuleLoading(_state_, _error_). 542 | 1. Else if _module_.[[LoadedModules]] contains a Record _record_ such that _record_.[[Specifier]] is _request_ LoadedModuleRequest Record _record_ such that ModuleRequestsEqual(_record_, _request_) is *true*, then 543 | 1. Perform InnerModuleLoading(_state_, _record_.[[Module]]). 544 | 1. Else, 545 | 1. Perform HostLoadImportedModule(_module_, _request_, _state_.[[HostDefined]], _state_). 546 | 1. NOTE: HostLoadImportedModule will call FinishLoadingImportedModule, which re-enters the graph loading process through ContinueModuleLoading. 547 | 1. If _state_.[[IsLoading]] is *false*, return ~unused~. 548 | 1. Assert: _state_.[[PendingModulesCount]] ≥ 1. 549 | 1. Set _state_.[[PendingModulesCount]] to _state_.[[PendingModulesCount]] - 1. 550 | 1. If _state_.[[PendingModulesCount]] = 0, then 551 | 1. Set _state_.[[IsLoading]] to *false*. 552 | 1. For each Cyclic Module Record _loaded_ of _state_.[[Visited]], do 553 | 1. If _loaded_.[[Status]] is ~new~, set _loaded_.[[Status]] to ~unlinked~. 554 | 1. Perform ! Call(_state_.[[PromiseCapability]].[[Resolve]], *undefined*, « *undefined* »). 555 | 1. Return ~unused~. 556 | 557 | 558 | 559 | 560 | 561 | 562 |

Source Text Module Records

563 | 564 |

An ImportEntry Record is a Record that digests information about a single declarative import. Each ImportEntry Record has the fields defined in :

565 | 566 | 567 | 568 | 571 | 574 | 577 | 578 | 579 | 582 | 586 | 590 | 591 | 592 | 595 | 596 | 597 | 598 | 599 | 602 | 603 | 604 | 605 |
569 | Field Name 570 | 572 | Value Type 573 | 575 | Meaning 576 |
580 | [[ModuleRequest]] 581 | 583 | String 584 | ModuleRequest Record 585 | 587 | String value of the |ModuleSpecifier| of the |ImportDeclaration|. 588 | ModuleRequest Record representing the |ModuleSpecifier| and import attributes of the |ImportDeclaration|. 589 |
593 | [[ImportName]] 594 |
600 | [[LocalName]] 601 |
606 | 607 | 608 | 609 | 610 |

611 | HostLoadImportedModule ( 612 | _referrer_: a Script Record, a Cyclic Module Record, or a Realm Record, 613 | _specifier_: a String, 614 | _moduleRequest_: a ModuleRequest Record, 615 | _hostDefined_: anything, 616 | _payload_: a GraphLoadingState Record or a PromiseCapability Record, 617 | ): ~unused~ 618 |

619 |
620 |
description
621 |
622 |
623 | 624 | 625 |

An example of when _referrer_ can be a Realm Record is in a web browser host. There, if a user clicks on a control given by

626 | 627 | 
<button type="button" onclick="import('./foo.mjs')">Click me</button>
628 | 629 |

there will be no active script or module at the time the `import()` expression runs. More generally, this can happen in any situation where the host pushes execution contexts with *null* ScriptOrModule components onto the execution context stack.

630 | 631 | 632 |

An implementation of HostLoadImportedModule must conform to the following requirements:

633 |
    634 |
  • 635 | The host environment must perform FinishLoadingImportedModule(_referrer_, _specifier__moduleRequest_, _payload_, _result_), where _result_ is either a normal completion containing the loaded Module Record or a throw completion, either synchronously or asynchronously. 636 |
    • 637 |
  • 638 |

    If this operation is called multiple times with the sametwo (_referrer_, _specifier__moduleRequest_) pairs such that:

    639 |
      640 |
    • the first _referrer_ is the same as the second _referrer_;
      • 641 |
    • ModuleRequestsEqual(the first _moduleRequest_, the second _moduleRequest_) is *true*;
      • 642 |
    • it performs FinishLoadingImportedModule(_referrer_, _specifier__moduleRequest_, _payload_, _result_) where _result_ is a normal completion,
      • 643 |
    644 |

    then it must perform FinishLoadingImportedModule(_referrer_, _specifier__moduleRequest_, _payload_, _result_) with the same _result_ each time.

    645 |
    • 646 |
  • 647 | The operation must treat _payload_ as an opaque value to be passed through to FinishLoadingImportedModule. 648 |
    • 649 |
650 | 651 |

The actual process performed is host-defined, but typically consists of performing whatever I/O operations are necessary to load the appropriate Module Record. Multiple different (_referrer_, _specifier_) pairs(_referrer_, _moduleRequest_.[[Specifer]], _moduleRequest_.[[Attributes]]) triples may map to the same Module Record instance. The actual mapping semantics is host-defined but typically a normalization process is applied to _specifier_ as part of the mapping process. A typical normalization process would include actions such as expansion of relative and abbreviated path specifiers.

652 | 653 | 654 | 655 |

656 | FinishLoadingImportedModule ( 657 | _referrer_: a Script Record, a Cyclic Module Record, or a Realm Record, 658 | _specifier_: a String, 659 | _moduleRequest_: a ModuleRequest Record, 660 | _payload_: a GraphLoadingState Record or a PromiseCapability Record, 661 | _result_: either a normal completion containing a Module Record or a throw completion, 662 | ): ~unused~ 663 |

664 |
665 |
description
666 |
667 |
668 | 669 | 1. If _result_ is a normal completion, then 670 | 1. If _referrer_.[[LoadedModules]] contains a RecordLoadedModuleRequest _record_ such that _record_.[[Specifier]] is _specifier_ModuleRequestsEqual(_record_, _moduleRequest_) is *true*, then 671 | 1. Assert: _record_.[[Module]] is _result_.[[Value]]. 672 | 1. Else, append the Record { [[Specifier]]: _specifier__moduleRequest_.[[Specifer]], [[Attributes]]: _moduleRequest_.[[Attributes]], [[Module]]: _result_.[[Value]] } to _referrer_.[[LoadedModules]]. 673 | 1. If _payload_ is a GraphLoadingState Record, then 674 | 1. Perform ContinueModuleLoading(_payload_, _result_). 675 | 1. Else, 676 | 1. Perform ContinueDynamicImport(_payload_, _result_). 677 | 1. Return ~unused~. 678 | 679 | 680 | 681 |

The description of the [[LoadedModules]] field of Realm Record, Script Record, and Cyclic Module Record should be updated to use LoadedModuleRequest Records.

682 | 683 | 684 | 685 | 686 |

687 | 688 | AllImportAttributesSupported ( 689 | _attributes_: a List of ImportAttribute Records, 690 | ): a Boolean 691 | 692 |

693 |
694 |
description
695 |
696 |
697 | 698 | 1. Let _supported_ be HostGetSupportedImportAttributes(). 699 | 1. For each ImportAttribute Record _attribute_ of _attributes_, do 700 | 1. If _supported_ does not contain _attribute_.[[Key]], return *false*. 701 | 1. Return *true*. 702 | 703 | 704 | 705 |

706 | 707 | HostGetSupportedImportAttributes ( ): a List of Strings 708 | 709 |

710 |
711 |
description
712 |
It allows host environments to specify which import attributes they support. Only attributes with supported keys will be provided to the host.
713 |
714 | 715 |

An implementation of HostGetSupportedImportAttributes must conform to the following requrements:

716 | 717 |
    718 |
  • It must return a List of Strings, each indicating a supported attribute.
    • 719 | 720 |
  • Each time this operation is called, it must return the same List with the same contents in the same order.
    • 721 | 722 |
  • An implementation of HostGetSupportedImportAttributes must always complete normally (i.e., not return an abrupt completion).
    • 723 |
724 | 725 |

The default implementation of HostGetSupportedImportAttributes is to return a new empty List.

726 | 727 | The purpose of requiring the host to specify its supported import attributes, rather than passing all attributes to the host and letting it then choose which ones it wants to handle, is to ensure that unsupported attributes are handled in a consistent way across different hosts. 728 | 729 | 730 | 731 | 732 | 733 |

Imports

734 | 735 | 736 | ImportDeclaration : 737 | `import` ImportClause FromClause WithClause? `;` 738 | `import` ModuleSpecifier WithClause? `;` 739 | 740 | 741 | WithClause : 742 | AttributesKeyword `{` `}` 743 | AttributesKeyword `{` WithEntries `,`? `}` 744 | 745 | AttributesKeyword : 746 | `with` 747 | 748 | WithEntries : 749 | AttributeKey `:` StringLiteral 750 | AttributeKey `:` StringLiteral `,` WithEntries 751 | 752 | AttributeKey : 753 | IdentifierName 754 | StringLiteral 755 | 756 | 757 | 758 | 759 |

Static Semantics: Early Errors

760 | 761 | 762 | 763 | WithClause : AttributesKeyword `{` WithEntries `,`? `}` 764 | 765 | 766 |
    767 |
  • It is a Syntax Error if WithClauseToAttributes of |WithClause| has two entries _a_ and _b_ such that _a_.[[Key]] is _b_.[[Key]].
    • 768 |
769 | 770 | 771 | 772 |

773 | 774 | Static Semantics: WithClauseToAttributes ( 775 | ): a List of ImportAttribute Records 776 | 777 |

778 |
779 |
780 | 781 | 782 | WithClause : AttributesKeyword `{` `}` 783 | 784 | 785 | 1. Return a new empty List. 786 | 787 | 788 | 789 | WithClause : AttributesKeyword `{` WithEntries `,`? `}` 790 | 791 | 792 | 1. Let _attributes_ be WithClauseToAttributes of |WithEntries|. 793 | 1. Sort _attributes_ according to the lexicographic order of their [[Key]] fields, treating the value of each such field as a sequence of UTF-16 code unit values. NOTE: This sorting is observable only in that hosts are prohibited from distinguishing among attributes by the order they occur in. 794 | 1. Return _attributes_. 795 | 796 | 797 | WithEntries : AttributeKey `:` StringLiteral 798 | 799 | 1. Let _key_ be the PropName of |AttributeKey|. 800 | 1. Let _entry_ be the ImportAttribute Record { [[Key]]: _key_, [[Value]]: SV of |StringLiteral| }. 801 | 1. Return « _entry_ ». 802 | 803 | 804 | WithEntries : AttributeKey `:` StringLiteral `,` WithEntries 805 | 806 | 1. Let _key_ be the PropName of |AttributeKey|. 807 | 1. Let _entry_ be the ImportAttribute Record { [[Key]]: _key_, [[Value]]: SV of |StringLiteral| }. 808 | 1. Let _rest_ be WithClauseToAttributes of |WithEntries|. 809 | 1. Return the list-concatenation of « _entry_ » and _rest_. 810 | 811 | 812 | 813 | 814 | 815 |

Exports

816 | 817 | 818 | ExportDeclaration : 819 | `export` ExportFromClause FromClause WithClause? `;` 820 | `export` NamedExports `;` 821 | `export` VariableStatement[~Yield, ~Await] 822 | `export` Declaration[~Yield, ~Await] 823 | `export` `default` HoistableDeclaration[~Yield, ~Await, +Default] 824 | `export` `default` ClassDeclaration[~Yield, ~Await, +Default] 825 | `export` `default` [lookahead <! {`function`, `async` [no |LineTerminator| here] `function`, `class`}] AssignmentExpression[+In, ~Yield, ~Await] `;` 826 | 827 | 828 | 829 | 830 | 831 | 832 |

Sample host integration: The Web embedding

833 | 834 |

The import attributes proposal is intended to give key information about how modules are interpreted to hosts. For the Web embedding and environments which aim to be similar to it, the string is interpreted as the "module type". This is not the primary way the module type is determined (which, on the Web, would be the MIME type, and in other environments may be the file extension), but rather a secondary check which is required to pass for the module graph to load.

835 | 836 |

In the Web embedding, the following changes would be made to the HTML specification for import attributes:

837 | 838 | 849 | 850 |

The module map is keyed by the absolute URL and the _type_. Initially no other import attributes are supported, so they are not present.

851 | 852 | -------------------------------------------------------------------------------- /tag-security-and-privacy.md: -------------------------------------------------------------------------------- 1 | # TAG Review: Security and Privacy questionnaire 2 | 3 | ## 2.1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary? 4 | 5 | This proposal only exposes the information to web servers that a particular resource is being fetched. This is necessary to load the module graph. 6 | 7 | The current proposal does not send any headers related to the import condition/module type for content negotiation, though this has been raised in [tc39/proposal-import-conditions#61](https://github.com/tc39/proposal-import-conditions/issues/61). 8 | 9 | 10 | ## 2.2. Is this specification exposing the minimum amount of information necessary to power the feature? 11 | 12 | Yes. 13 | 14 | ## 2.3. How does this specification deal with personal information or personally-identifiable information or information derived thereof? 15 | 16 | HTML imports modules by performing fetches from the URL indicated in the module specifier. JavaScript code may construct a URL exposing personally identifying information which is implicitly communicated by importing a module with that URL, but this is already possible with JS modules. 17 | 18 | No new identifying information is communicated by this proposal. 19 | 20 | ## 2.4. How does this specification deal with sensitive information 21 | 22 | No extra sensitive information is exposed by this proposal. 23 | 24 | ## 2.5. Does this specification introduce new state for an origin that persists across browsing sessions? 25 | 26 | No. 27 | 28 | ## 2.6. What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin? 29 | 30 | None. 31 | 32 | ## 2.7. Does this specification allow an origin access to sensors on a user’s device 33 | 34 | No. 35 | 36 | ## 2.8. What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts. 37 | 38 | No data. 39 | 40 | ## 2.9. Does this specification enable new script execution/loading mechanisms? 41 | 42 | This proposal will enable future module types on the web, first JSON module and then HTML, CSS, ... 43 | 44 | This will be done via the `type` attribute, which is designed to let the importer specify whether the imported module has the capability to execute code: some module types are able to execute code, while others are not. 45 | 46 | ## 2.10. Does this specification allow an origin to access other devices? 47 | 48 | No. 49 | 50 | ## 2.11. Does this specification allow an origin some measure of control over a user agent’s native UI? 51 | 52 | No. 53 | 54 | ## 2.12. What temporary identifiers might this specification create or expose to the web? 55 | 56 | No identifiers. 57 | 58 | ## 2.13. How does this specification distinguish between behavior in first-party and third-party contexts? 59 | 60 | This specification allows importing more kinds of cross-origin subresources as modules, analogous to how ES modules work. The imported subresources are not distinguished and generally treated as "first-party", but each new subresource types will be importable only with the explicit use of a `type` assertion, which avoids giving the subresource unnecessary capabilities (including both executing code and accessing parsers). 61 | 62 | ## 2.14. How does this specification work in the context of a user agent’s Private Browsing or "incognito" mode? 63 | 64 | No difference. 65 | 66 | ## 2.15. Does this specification have a "Security Considerations" and "Privacy Considerations" section? 67 | 68 | Part of the proposal motivation is the security aspect, as explained in the [README.md#motivation](https://github.com/tc39/proposal-import-conditions/blob/master/README.md#motivation). 69 | We consider that there are no particular privacy considerations. 70 | 71 | ## 2.16. Does this specification allow downgrading default security characteristics? 72 | 73 | No. 74 | 75 | ## 2.17. What should this questionnaire have asked? 76 | 77 | The questions seem adequate. 78 | --------------------------------------------------------------------------------