deno_graph

Adds an build option that lets , , , , and files be imported as modules. When the option is enabled, such a file is rewritten into a JavaScript module that parses its contents with a parser pulled from the registry on demand: Because the parser becomes an ordinary graph dependency, the feature is zero-cost when unused: nothing about it enters the module graph (or a compiled binary, or the lockfile) unless a config file is actually imported. yaml and toml are detected from the file extension so no new variant is needed; json5 and jsonc are detected from their extension or media type. The import attribute is honored ( etc.), and json5 and jsonc additionally satisfy . The mapping is yaml to , toml to , jsonc to , and json5 to (there is no ). The contents are inlined as a string literal rather than imported via , because the rewritten module occupies the file's specifier in the graph, so a text self-import would read back the generated source instead of the original bytes. This is the deno_graph half of denoland/deno#35304; the deno side wires the option to and handles the runtime module type.

Adds an build option, mirroring the existing and options. When enabled, a import attribute type is accepted and the import is recorded as an asset edge (external module) in the graph; when disabled, it errors with the same unsupported import attribute type error as before. This unblocks CSS module scripts () in Deno behind , prototyped in denoland/deno#35093 (towards denoland/deno#11961). Once this lands and is released, the analyzer-level workaround in that PR (remapping to for graph building) can be replaced with this option.