Should std:nonexistent cause parse error or fetch error?

[hiroshige-g]

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 between import statements and <script>'s src attributes (e.g. import maps are applied or not), but anyway creating an issue to track and explain this explicitly.

• (1): with built-in modules but without import maps spec
• (2) with import maps spec (current, HTML-spec based)
• (3) with import maps spec (Fetch-spec based)

Request type	error type (1)	spec (1)	error type (2)	spec (2)	error type (3)
<script type="module" src="std:nonexistent">	fetch error	Fetching just fails	fetch error	Throw in validation	fetch error
import 'std:nonexistent';	fetch error	Fetching just fails	parse error	Throw in validation	fetch error
import 'std:nonexistent'; + import map: "std:nonexistent": "std:nonexistent"	N/A	N/A	parse error	Throw in Step 1.1.2.2 of resolve-an-imports-match	fetch error
import 'std-internal:some'; from non-internal	N/A	N/A	parse error	Throw in validation	parse error?

[guybedford]

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'?

[domenic]

Built-in module support was removed in #176 so this is no longer applicable.