Commit activity
Last 12 weeks · 19 commits
Community health
2 of 6 standards met
37
✓README✓License○Contributing○Code of Conduct○Issue Template○PR Template
Recent PRs & issues
Active · Last activity 8h ago
See all on GitHub →
Three independent reasons CI has been red, none of them a real test failure. Pin the ecosystem suite to a stable Deno release The ecosystem expectations capture output verbatim, so they are coupled to whatever TypeScript version the Deno binary ships. Running the suite against meant every upstream change to type checking turned all 12 shards red without anything in this repo changing. The current instance is denoland/deno#35938, which switched over to native tsc — that landed 8 days after the last green ecosystem run, and it rewrites diagnostics across ~950 spec files. It has not shipped in a stable release yet: 2.9.5 stable passes the current expectations, only canary fails. Pinning to an exact stable release rather than tracking or makes a Deno bump a deliberate change that lands together with the regenerated expectations in the same commit. #663 holds the regenerated-for-native-tsc expectations for whenever that behaviour does reach stable. One spec () is regenerated here: it was last generated against canary, which renders the declaration quoted in a TS2552 hint differently. A full local run confirms it is the only one of the 7555 that differs between canary and 2.9.5 stable. Stop tooling deps from dirtying the workspace lockfile Recent Deno versions record the deps of a remote script in the enclosing workspace lockfile. Both (wasmbuild) and the script did that during the job, so the inside aborted with "Aborting due to uncommitted changes". Both are tooling deps rather than project deps, so they now run with . Make the JSR mirror robust With the two above fixed, the remaining red shards all failed in rather than in a test. Three bugs there: . Download tasks were built as , so the promise started running the moment the generator yielded it. When the manifest-fetch pool feeding that generator threw, the outer pool tore down and every already-yielded promise was left with nobody awaiting it. Package versions are now mirrored as self-contained units, so no promise outlives its consumer. Versions marked complete before their files existed. — the marker a later run checks to decide a version is already mirrored — was written before the file downloads it had yielded finished, so a cached mirror could skip a package whose files were never written. That surfaces much later as "Module not found" in some unrelated spec. The marker is now written after the downloads it covers complete. Silently truncated files.** A connection dropped mid-body left a well-formed but short file behind, surfacing as a bogus syntax error elsewhere. Downloads are now checked against the size the manifest records. A single bad package version also no longer abandons the rest of the mirror: failures are collected and reported together at the end, unwrapped from the / layers that were hiding the actual message.
Untagged template literals were always inferred as , but in a const position TypeScript infers the string literal type: | `hello world"hello world"stringhello world"hello world"stringhello worldstringstringhi ${foobar}stringstringhello"hello"stringtpl_to_ts_type()swc_helpers.rsstringstring.d.tsstringhi ${string}.ts` emit leaves the expression as-is, so it stays correct there. Closes https://github.com/jsr-io/jsr/issues/453 Closes #458
The ecosystem shards have been red on main — and therefore on every PR — since mid-July. Cause: switched from the forked in-isolate TypeScript to the native compiler ( / tsgo) in denoland/deno#35938, merged 2026-07-17. The last green ecosystem run here was 2026-07-09, eight days earlier, so every expectation in was recorded with the old checker. Confirmed it is not any one PR: an empty commit on main (, zero code changes) fails with the same 923 specs as #661 and #662, shard for shard. Regenerated against deno 2.9.5+98f9507 (canary) with , then verified with a plain — 7555 passed. Diagnostics moved in both directions: Dominant new codes among the regressions: TS2694 (201), TS5089 (90), TS2846 (38), TS2709 (33), TS2305 (29), TS2306 (24). Two things worth a look before this is treated as settled: TS2846** — "A declaration file cannot be imported without 'import type'" — fires on ordinary Deno code that the old checker accepted. Minimal repro: type-checks clean on deno 2.9.1 stable and fails on canary. If that is an unintended tsgo behaviour, these 38 expectations encode a bug. The native compiler version is pinned by deno, so this will need regenerating again as canary moves. Pinning in to a fixed build would make the suite reproducible, at the cost of no longer catching canary breakage early.
Recent fixes
First half of the fix for denoland/deno#35879 ( can fail after a successful due to JSR resolution divergence with type-only imports). The second half is a small deno CLI change that sets the new flag when running with . Problem resolves the type-inclusive graph; (no type-checking) resolves a code-only graph. When an exact JSR pin is reachable only through a type-only import and another dependency requires a semver range on the same package, the cache-building command unifies the range onto the pinned (older) version and materializes only that version. The runtime graph doesn't contain the pin, re-resolves the range against the cached package to the newest matching version, and fails under because that version's manifest was never fetched: (Real-world instance in denoland/deno#35879: Lume pins on a type-only path while requires ; the moment was published, every lockfile-less build/run pair broke with no change to the project.) Change Adds an opt-in (default , so nothing changes for existing consumers). When enabled, resolving a semver range inserts a new step 1.5 into , between in-graph unification (step 1) and unyanked registry versions (step 2): resolve the range against the set of matching, unyanked versions whose is already in the cache (probed via with , which by contract returns when not cached). The placement makes the flag strictly error-converting for cached-only consumers (rationale also in a code comment): Step 1 stays first, so in-graph unification still wins — matching online behavior when a code-edge pin exists in the graph. 1.5 is not merged into step 1's candidate iterator: if the graph unified onto an older version while a newer matching version is also cached, chaining would diverge from what an online run resolves. Before step 2, the change can only convert errors into successes: if step 2's best pick is cached it equals the best cached match here; if it isn't cached, step 2's pick fails to load today. Yanked versions are never selected from the cached set (consistent with step 2 preceding step 3). Tests — lists 1.0.10/1.0.11, only 1.0.10's manifest cached, flag on → range resolves to 1.0.10. — same fixture, flag off → today's behavior (resolves 1.0.11 and fails to load it). — code-edge exact pin + range with both versions cached, flag on → unification wins (both resolve to the pin). , , and are green. Notes for review The cached-manifest probe runs per pending req when the flag is on (one cache-only load per matching version), even when step 1 unification would decide. Probes are local cache reads, so this is kept simple; it could be skipped when the graph already has a matching selection or memoized per package if you'd prefer. is applied in step 1.5 the same way as step 2 (unlike step 1, which ignores it), keeping 1.5's candidate set a strict subset of step 2's.
Refreshes the ecosystem snapshots that are currently red on CI (surfaced on #658, 2026-07-09). Regenerated with against canary , and verified green without afterwards. Specs refreshed: … , All are canary drift, not registry drift (an earlier attribution in #659 was wrong — see the correction comment there): — bisected to denoland/deno#35639 ("defer web-platform globals to lib.dom in deno libs"): the error set (TS2304/TS2552) is unchanged, but the TS2552 related-information snippet quotes 's declaration, whose text changed with the lib restructuring ( → form). and ** — → from the Deno 2.8 → 2.9 transition (npm types resolution improved: no longer errors on 's default import, TS1192; no longer errors on the namespace, TS2503). The minimal repro fails on Deno 2.8.3 (matching the old snapshots) and passes on 2.9.1+. The main ecosystem workflow has in fact been red for these since 2026-06-22 (last green: 2026-06-10) — it went unnoticed because it isn't a required check. Note: beyond the snapshot refresh, the process problem is that the ecosystem workflow stayed red on main for weeks without anyone noticing — #659's correction comment discusses that; this PR just brings the snapshots in line with what CI observes today. Closes #659
Summary The ecosystem suite's TYPE CHECK phase is not hermetic: its verdicts depend on live npm registry state, not only on the pinned inputs and the Deno canary it runs against. Two of the three ecosystem failures currently visible on CI (first observed on #658, 2026-07-09) are not canary drift — the exact canary binary that produced a green run on 2026-07-06 now produces a different verdict for the same specs, on the same inputs. How the suite compares things (context) Each ecosystem spec builds a real JSR package (from the local ) through deno_graph fast check, extracts it into a tmpdir with the fast-check output substituted, then shells out to using the on PATH (CI: ), and compares the full output — fast-check diagnostics, TYPE CHECK PASSED/FAILED, and the diagnostic text — against the committed snapshot. That gives the comparison two unpinned inputs: 1. The canary toolchain — known and routinely handled (#645, #654 expectation chores). 2. The live npm registry — less obvious. The embedded lockfile integrity-pins npm tarballs*, but packuments (registry metadata documents) are not pinned, and the check phase talks to the real registry. Case study: the three failures on 2026-07-09 Evidence that mebus/ipinfo are not canary (or platform) drift 's last green ecosystem run (2026-07-06) installed canary — i.e. that binary produced for both specs on that day (matching the snapshots). Running the same harness (, with the spec's package hand-mirrored into ) with that exact canary binary now yields for both specs — reproduced on macOS (aarch64) and Linux x86_64 (docker), with the snapshot-embedded v3 lockfile in force. Same binary + integrity-pinned tarballs + same lockfile + both platforms, different date → different verdict. The only unpinned input in the check phase is registry metadata. Both flips are npm-types-resolution-sensitive (zod's default-export detection; puppeteer's namespace types) and flipped in the same direction in the same window, which suggests a registry-side serving/metadata change rather than anything in this repo or in Deno. Repro tooling notes, for re-verification: per-commit canaries are downloadable from , and a single spec can be run without the full mirror by hand-populating just that package under ( + fetched from jsr.io). Why this matters Ecosystem shards can turn red on any PR without any change in this repo or in Deno, and the failure looks identical to canary drift. Attribution requires the kind of archaeology above. Snapshots that record registry-dependent verdicts (like the two above) are recordings of a moving target: re-recording them today (as the usual expectations chore does) is correct but may flip again. Possible directions 1. Pin the registry metadata the check phase sees, analogous to the existing JSR mirror (e.g. mirror packuments for the locked package set, serve via /a local registry stub). 2. Make the check phase cached-only: pre-warm a per spec from pinned inputs, then run so no live registry data can influence the verdict. 3. At minimum, document the two drift sources next to the suite and in the routine expectations-chore playbook, so red shards get triaged quickly. The immediate expectations refresh for the three specs above will be a separate PR referencing this issue.
Structured data for AI agents
Repository: denoland/deno_graph. Description: The module graph logic for Deno CLI Stars: 137, Forks: 46. Primary language: Rust. Languages: Rust (95.8%), TypeScript (4.2%). License: MIT. Homepage: https://docs.rs/deno_graph Topics: deno, rust, typescript, webassembly. Latest release: 0.110.2 (1mo ago). Open PRs: 8, open issues: 32. Last activity: 8h ago. Community health: 37%. Top contributors: dsherret, denobot, kitsonk, bartlomieju, nayeemrmn, lucacasonato, kt3k, crowlKats, marvinhagemeister, nathanwhit and others.