← back to v155 · import-text-text-modules
conformance · v155
v155 · import-text-text-modules — conformance probe
6 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.
0
pass
0
fail
0
blocked
6
total
| id | contract | kind | verdict | detail |
|---|---|---|---|---|
import-attributes-syntax-parses |
The `with` options bag on dynamic import parses. Text modules are an import attribute, so this is the syntax they are built on. spec ↗ | script | … | |
text-fixture-served-as-text-plain |
The fixture is served with a text/* Content-Type. A text module is still a module fetch, so a mislabelled response would fail the import for a reason unrelated to the feature. spec ↗ | script | … | |
text-import-yields-a-string |
Importing a file with type "text" must resolve to a module whose default export is a string containing the file's contents. spec ↗ | script | … | |
text-import-default-is-the-only-export |
A text module exposes exactly one export, the default. Extra named exports would mean the loader is doing more than handing back a string. spec ↗ | script | … | |
text-import-is-cached-by-specifier |
The module map caches by specifier, so importing the same URL twice returns the identical module object. This is what makes a text import a dependency rather than an operation. spec ↗ | script | … | |
missing-text-module-rejects |
A missing file must reject the import. fetch() resolves for a 404 and leaves the check to the caller; an import cannot be ignored by accident, which is the practical difference between the two. spec ↗ | script | … |