Publishing a package with a stable `with { type: "text" }` import fails server-side: registry analysis builds its graph with `unstable_text_imports: false`

[rickylabs]

Summary

Publishing any package that uses a runtime-stable text import (with { type: "text" }, stabilized in Deno 2.8 via denoland/deno#34238) fails during registry-side processing with:

failed to build module graph: The import attribute type of "text" is unsupported.
  Specifier: file:///README.md
    at file:///cli.ts:18:27

deno publish --dry-run accepts the exact same package — the rejection only surfaces on the real authenticated publish, which makes it invisible to every local/CI preflight.

Originally filed against Deno as denoland/deno#35546. After tracing both codebases, the Deno CLI is not at fault: since denoland/deno#34692 the client-side publish path (graph build, diagnostics, tarball) permits stable text imports, and dry-run vs. real publish share an identical client pipeline (dry-run simply stops before upload). The error string originates in deno_graph's asset-load gate, raised from this repository's publishing-task analyzer, which builds its own module graph with text imports disabled.

Root cause (in this repo)

Pipeline: POST /scopes/.../versions/... → process_publishing_task (api/src/publish.rs:188) → process_tarball (api/src/tarball.rs:102) → analyze_package (api/src/tarball.rs:340 → api/src/analysis.rs:79).

analyze_package_inner builds a fresh deno_graph::ModuleGraph over the uploaded tarball with:

unstable_bytes_imports: false,
unstable_text_imports: false,   // api/src/analysis.rs:167  ← rejects stable text imports
unstable_css_imports: false,

deno_graph then classifies the import as an asset load and graph.valid() surfaces UnsupportedImportAttributeType (deno_graph src/graph.rs:3040 / :5545), which api/src/tarball.rs:643 wraps into the publish error.

A second identical omission exists in the npm-tarball rebuild path (rebuild_npm_tarball_inner, api/src/analysis.rs:566-609, flags at :602-605).

Reproduction

Any minimal package with import text from "./asset.txt" with { type: "text" }: deno publish --dry-run → success; real publish → the error above. Hit in production publishing @netscript/mcp@0.0.1-beta.10 on 2026-07-17 (Deno 2.9.0); internal tracking: rickylabs/netscript#810.

Notes

• Bytes imports remain unstable in Deno, so keeping unstable_bytes_imports: false is presumably still correct — this report is about text imports only.
• One policy consideration for maintainers: JSR's npm compatibility layer does not rewrite with { type: "text" } for Node consumers, so you may want to sequence npm-tarball handling (e.g. inlining) with the flag flip. A proposed minimal fix follows in a comment.

Cross-references: denoland/deno#35546 (original report, can be closed/transferred in favor of this one), denoland/deno#34238 (stabilization), denoland/deno#34692 (client-side publish fix), rickylabs/netscript#810 (production impact).

[rickylabs]

Proposed minimal fix (verified against the code paths above — happy to defer to maintainers on the npm-mirror sequencing)

File: api/src/analysis.rs — 2 lines, both graph-build sites:

@@ analyze_package_inner (BuildOptions, ~line 167)
-        unstable_text_imports: false,
+        // text imports are runtime-stable since Deno 2.8 (denoland/deno#34238)
+        unstable_text_imports: true,

@@ rebuild_npm_tarball_inner (BuildOptions, ~line 602-605)
-        unstable_text_imports: false,
+        unstable_text_imports: true,

Why this appears sufficient without a dependency bump:

• The pinned deno_graph 0.109 already exposes the unstable_text_imports build option with the same semantics the Deno CLI uses (cli/graph_util.rs:930 enables it unconditionally since stabilization).
• The tarball SyncLoader (api/src/analysis.rs:461-493) serves any file: path from the uploaded file map, so the text-imported asset resolves; an asset excluded from the publish set still fails correctly as "Module not found".
• Allowed text imports surface as Module::External { was_asset_load: true }, and the existing graph walks already have exhaustive Module::External arms (e.g. api/src/api/package.rs:2527-2530, 2547-2550, returning None for size/media-type — correct for assets).
• unstable_bytes_imports stays false (bytes imports are still unstable in Deno).

Test suggestion: publish integration tests alongside the existing graph-error cases in api/src/publish.rs (~1111/1371): (a) text import of an included asset → publish succeeds; (b) type: "bytes" → still rejected; (c) text import of a file excluded from the publish set → "Module not found".

Known trade-off to decide deliberately: the npm compatibility tarball won't rewrite with { type: "text" } for Node, so text-importing packages would degrade on the npm mirror until an inlining/transpile step exists — that may be the reason the flag was gated, and maintainers may prefer to land that step first or accept the degradation for JSR-native consumers.

Not opening a PR to leave the sequencing call with the team — but can do so if wanted. /cc rickylabs/netscript#810, denoland/deno#35546

[rickylabs]

Dedup diligence: searched existing issues before filing — no prior report of this specific analyzer-flag rejection. Related but distinct: #427/#418 banned the old import assertions syntax at publish (pre-attributes era); #987/#1245/#293 discuss asset export/consumption on the consumer side. This issue is narrowly about the publishing-task analyzer rejecting the now-stable type: "text" attribute.