Closed hiroshige-g closed 4 years ago
The fact that rows (2) and (3) in the table above are different does seem somewhat surprising, in that I would have expected that import maps only change behaviour at a resolution level, and not the overall resolution semantics.
The core of this discrepancy does exactly seem to be the 1.1.2.2 step in resolve-an-imports-match, which seems to be an early validation unlike we get at any other part of the resolver.
I can understand std-internal:some
being an early validation as that is a sort of "resolver policy" restriction, which is a new lower-level layer though.
The reason for 1.1.2.2 seems to be this comment:
This condition is added to ensure that moduleMap[url] does not exist for unimplemented built-ins. Without this condition, fetch a single module script might be called and moduleMap[url] can be set to null, which might complicates the spec around built-ins.
@hiroshige-g could you clarify the concern here? I was under the impression the module map cached error results just like it caches import 'std:nonexistent'
?
Built-in module support was removed in #176 so this is no longer applicable.
In some cases
std:nonexistent
causes parse errors and in other cases fetch errors. This is probably fine, as we already have larger behavior differences betweenimport
statements and<script>
'ssrc
attributes (e.g. import maps are applied or not), but anyway creating an issue to track and explain this explicitly.<script type="module" src="std:nonexistent">
import 'std:nonexistent';
import 'std:nonexistent';
+ import map:"std:nonexistent": "std:nonexistent"
import 'std-internal:some';
from non-internal