7 | title: Dynamic Import Host Adjustment 8 | stage: 0 9 | contributors: Mike Samuel 10 |11 | 12 |
This proposal allows the host to inspect and adjust the argument, 13 | _x_, in `import(x)` so that Trusted Types can use runtime-type 14 | information to decide whether to allow the import to proceed.
15 | 16 |For more detail see the 17 | explainer.
18 | 19 |This proposal lays out two options:
20 | 21 |First, this proposal adjusts `import(...)` to stringify its argument 31 | via a host callout.
32 |Second, this proposal defines the new host callout.
55 |HostDynamicValueToSpecifier is an implementation-defined
60 | abstract operation that converts a runtime value representing a
61 | module specifier, _specifier_, to a string that corresponds to a
62 | |ModuleSpecifier| String. The host also receives the Script
63 | Record or Module Record, _referencingScriptOrModule_.
64 | _referencingScriptOrModule_ may be *null*, if the
65 | resolution is being performed in the context of
66 | an
The default implementation performs the following steps:
71 |The implementation of HostDynamicValueToSpecifier must 76 | conform to the following requirements:
77 |Like the first option, this proposal adjusts `import(...)` to not stringify 94 | its argument too early. 95 | This means that HostImportModuleDynamically could pass given a 96 | TrustedModuleSpecifier but not given a raw string.
97 |HostImportModuleDynamically is an implementation-defined abstract
130 | operation that performs any necessary setup work in order to make
131 | available the module corresponding to the |ModuleSpecifier| String,
132 | _specifier_, occurring within the context of the script or module
133 | represented by the Script Record or Module Record
134 | _referencingScriptOrModule_. (_referencingScriptOrModule_ may also
135 | be *null*, if there is no active script or module when
136 | the
The implementation of HostImportModuleDynamically must conform to 141 | the following requirements:
142 | 143 |This is necessary to prevent a different apparent order of operation 161 | that could occur if user code received the module promise before 162 | _specifier_ is stringified.
163 | 164 |A non-conforming implementation might behave improperly for:
165 |
166 | const modulePromise = import({
167 | toString() {
168 | console.log('stringified');
169 | return './foo';
170 | },
171 | };
172 | console.log('got promise');
173 | modulePromise.then(
174 | () => { console.log('module resolved'); },
175 | () => { console.log('module rejected'); });
176 |
177 | // Before: stringified, got promise, module ...
178 | // ⤩
179 | // Non-conforming: got promise, stringified, module ...
180 | Since _specifier_ is not a string, the same would mean 240 | less, but this is not necessary to preserve any single-fetch requirement 241 | since FinishDynamicImport delegates to HostResolveImportModule which says
242 |243 | "This operation must be idempotent if it completes 244 | normally. Each time it is called with a specific 245 | _referencingScriptOrModule_, _specifier_ pair as arguments 246 | it must return the same Module Record instance." 247 |248 |
The actual process performed is implementation-defined, but 259 | typically consists of performing whatever I/O operations are 260 | necessary to allow HostResolveImportedModule to synchronously 261 | retrieve the appropriate Module Record, and then calling its 262 | Evaluate concrete method. This might require performing similar 263 | normalization as HostResolveImportedModule does.
264 |Finally, we adjust FinishDynamicImport to use the module specifier 271 | string computed by the host callout.
272 |FinishDynamicImport completes the process of a dynamic import
277 | originally started by an
278 |
This proposal allows the host to inspect and adjust the argument,
1811 | x, in import(x) so that Trusted Types can use runtime-type
1812 | information to decide whether to allow the import to proceed.
For more detail see the 1815 | 1816 | explainer.
1817 | 1818 |This proposal lays out two options:
1819 | 1820 |First, this proposal adjusts import(...) to stringify its argument
1830 | via a host callout.
Second, this proposal defines the new host callout.
1847 |HostDynamicValueToSpecifier is an implementation-defined
1852 | abstract operation that converts a runtime value representing a
1853 | module specifier, specifier, to a string that corresponds to a
1854 | import()
The default implementation performs the following steps:
1863 |The implementation of HostDynamicValueToSpecifier must 1867 | conform to the following requirements:
1868 |Like the first option, this proposal adjusts import(...) to not stringify
1885 | its argument too early.
1886 | This means that
HostImportModuleDynamically is an implementation-defined abstract
1916 | operation that performs any necessary setup work in order to make
1917 | available the module corresponding to the import()
The implementation of HostImportModuleDynamically must conform to 1927 | the following requirements:
1928 | 1929 |This is necessary to prevent a different apparent order of operation 1949 | that could occur if user code received the module promise before 1950 | specifier is stringified.
1951 | 1952 |A non-conforming implementation might behave improperly for:
1953 |const modulePromise = import({
1954 | toString() {
1955 | console.log('stringified');
1956 | return './foo';
1957 | },
1958 | };
1959 | console.log('got promise');
1960 | modulePromise.then(
1961 | () => { console.log('module resolved'); },
1962 | () => { console.log('module rejected'); });
1963 |
1964 | // Before: stringified, got promise, module ...
1965 | // ⤩
1966 | // Non-conforming: got promise, stringified, module ...Since specifier is not a string, the same would mean
2030 | less, but this is not necessary to preserve any single-fetch requirement
2031 | since
2033 | "This operation must be idempotent if it completes 2034 | normally. Each time it is called with a specific 2035 | referencingScriptOrModule, specifier pair as arguments 2036 | it must return the same2039 |Module Record instance." 2037 | 2038 |
The actual process performed is implementation-defined, but
2051 | typically consists of performing whatever I/O operations are
2052 | necessary to allow
Finally, we adjust FinishDynamicImport to use the module specifier 2063 | string computed by the host callout.
2064 |FinishDynamicImport completes the process of a dynamic import
2069 | originally started by an
2070 |
2071 | import()
© 2019 Mike Samuel
2083 | 2084 |All Software contained in this document ("Software") is protected by copyright and is being made available under the "BSD License", included below. This Software may be subject to third party rights (rights from parties other than Ecma International), including patent rights, and no licenses under such third party rights are granted under this license even if the third party concerned is a member of Ecma International. SEE THE ECMA CODE OF CONDUCT IN PATENT MATTERS AVAILABLE AT https://ecma-international.org/memento/codeofconduct.htm FOR INFORMATION REGARDING THE LICENSING OF PATENT CLAIMS THAT ARE REQUIRED TO IMPLEMENT ECMA INTERNATIONAL STANDARDS.
2086 | 2087 |Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
2088 | 2089 |THIS SOFTWARE IS PROVIDED BY THE ECMA INTERNATIONAL "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ECMA INTERNATIONAL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
2096 | 2097 |