denoland/deno · error · anyhow::Error
unsupported media type
Error message
unsupported media type {} for {} What it means
When eszip stores a module in its JavaScript source slot, it handles a fixed set of media types (JS/JSX served as-is, TS/TSX transpiled with the given emit options). If the module's media type falls into the catch-all arm, the build rejects it with 'unsupported media type <type> for <specifier>' — the module kind cannot be represented as embedded JS source.
Solutions
- Import real JS/TS modules; load assets with Deno.readFile/inline bytes instead of `import`
- Give the file a .js/.ts (or .mjs/.mts) extension so it maps to a supported media type
- For local dev servers, send correct Content-Type (text/javascript or application/typescript) for module responses
- If you need Wasm, use WebAssembly APIs / a loader path that stores it as a Wasm module rather than a JS-source slot
Example fix
// before
import shaderSrc from "./shader.wasm"; // unsupported media type Wasm
// after
const shaderBytes = await Deno.readFile(new URL("./shader.wasm", import.meta.url)); Defensive patterns
Strategy: validation
Validate before calling
// Reject non-code imports before building
const CODE_EXT = /\.(m?jsx?|m?tsx?|json|jsonc)$/;
export function assertImportable(specifier: string) {
if (!CODE_EXT.test(new URL(specifier, import.meta.url).pathname)) {
throw new Error(`Refusing to import non-code asset as module: ${specifier}`);
}
} Type guard
function isEmbeddableMediaType(path: string): boolean {
return /\.(m?jsx?|m?tsx?|json|jsonc)$/i.test(path);
} Try / catch
const { success, stderr } = await new Deno.Command("deno", { args: ["compile", "src/mod.ts"] }).output();
const err = new TextDecoder().decode(stderr);
const m = err.match(/unsupported media type (\S+) for (\S+)/);
if (!success && m) switchToAssetLoader(m[2]); // readFile instead of import Prevention
- Load binary/asset files with Deno.readFile, never `import`
- Give modules recognized extensions (.ts/.js); avoid extensionless imports
- Serve correct Content-Type from local dev servers feeding deno
When it happens
Trigger: A static import resolving to a file with an extension Deno maps to a non-code type (e.g. .wasm, .html, .sql, .md or an unknown/extensionless type under certain media-type providers) being visited as a regular module; a server serving JS content with a Content-Type that deno_graph classifies as something else.
Common situations: Importing asset files as if they were JS modules (works in bundlers with asset loaders, not in Deno's eszip path); extensionless files or misconfigured media types on dev servers; older Deno versions classifying some extensions differently than the current runtime.
Related errors
- module not found
- failed to load
- Could not resolve package req
- Unknown media type value
- An executable name was not provided. One could not be…
AI-assisted analysis of denoland/deno@9ad36f7a2c (2026-08-20).
Data as JSON: /api/errors/49c27814bdaf688c.
Report an issue: GitHub.
Appendix: source
Thrown at libs/eszip/v2.rs:1438
}
_ => Cow::Borrowed(emit_options),
};
let emit = parsed_source
.transpile(
transpile_options,
&TranspileModuleOptions {
module_kind: module_kind_provider.module_kind(module),
},
&emit_options,
)?
.into_source();
source = emit.text.into_bytes().into();
source_map = Arc::from(
emit.source_map.map(|s| s.into_bytes()).unwrap_or_default(),
);
}
_ => {
return Err(anyhow::anyhow!(
"unsupported media type {} for {}",
module.media_type,
visited.specifier()
));
}
};
let eszip_module = EszipV2Module::Module {
kind: ModuleKind::JavaScript,
source: EszipV2SourceSlot::Ready(source),
source_map: EszipV2SourceSlot::Ready(source_map),
};
modules.insert(specifier_key.into_owned(), eszip_module);
Ok(Some(Box::new(module.dependencies.values().filter_map(
|dependency| {
Some(ToVisit::Module {
specifier: dependency.get_code()?,View on GitHub (pinned to 9ad36f7a2c)