🐛 Take glob-to-regexp from npm so its types stop drifting - #75
Merged
Merged
Conversation
`deno task test` has failed on every pull request since at least March:
TS2305 Module '.../@types/glob-to-regexp@0.4.4/index.d.ts'
has no exported member 'default'
`?pin=v132` pins the runtime package at 0.4.1, but esm.sh resolves the types
separately and now serves `@types/glob-to-regexp@0.4.4`, which declares
`export = GlobToRegExp` and so has no default to re-export. The pin covered
the code and not the types, so the types moved out from under it.
Deno does the interop itself for an `npm:` specifier, which is also the
direction this repo already took in "convert inline URL imports to bare
specifiers".
`hash.js` on the next line has the same shape but esm.sh serves no types for
it, so there is nothing there to drift.
`deploy-preview` never started the Fresh server:
Integrity check failed for remote specifier.
Specifier: https://esm.sh/prismjs@1.27.0/components/prism-diff.js?no-check
Actual: 2f4bb643…
Expected: 39fc9d5a…
esm.sh re-serves that url with different bytes than when the lock was
written, so every run failed the check and timed out after five minutes.
`--reload` does not help: deno still validates against the recorded hash.
The lockfile is rebuilt. Regenerating it also moved `@libs/xml` from 7 to 8,
because `sitemap.xml.ts` imported it with no version at all, so the import
is pinned and the lock keeps the 7 the site is running. 8 renders the
sitemap correctly too — worth taking deliberately rather than as a side
effect of a lockfile rebuild.
|
🚀 Deploy Preview Ready!
|
cowboyd
approved these changes
Sep 30, 2026
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Verifyfails on every pull request to this repo, and has since at least2026-03-03 — the runs on
Deploy To Netlify (#72)and on the merge of #73 failwith the same error:
?pin=v132pins the runtime package at 0.4.1, but esm.sh resolves the typedeclarations separately and now serves
@types/glob-to-regexp@0.4.4, which isCommonJS-shaped:
There is no
defaultto re-export. TypeScript's synthetic-default interop letsyou import from a module like that, but it does not invent a
defaultbinding for
export { default as … } from, so the check is right to fail. Thepin covered the code and not the types, and the types moved out from under it.
Approach
Deno does the CommonJS interop itself for an
npm:specifier, and takes thetypes from the package rather than from a separately-resolved URL, so there is
nothing left to drift.
It is also the direction this repo already took, in
✨ convert inline URL imports to bare specifiers.I tried keeping the esm.sh url and splitting the re-export into an
importfollowed by an
export; it fails the same way, so the specifier itself has tochange.
hash.json the next line has the same shape, but esm.sh serves no@typesfor it, so there is nothing there to drift. Left alone.
Tests
All three steps the
Verifyworkflow runs now pass locally, wheredeno task testpreviously failed on the type check:I also confirmed the replacement works at runtime, not only in the type
checker —
globToRegExp("*.ts")returns/^.*\.ts$/.deno.lockgains the npm entry, and along with it the@std/assertand@std/internalentries the lockfile had been missing since the bare-specifierconversion.
Note
Unrelated to #74, which touches only
deno.jsonand a route template. That PRis failing on this same pre-existing error and should go green once this lands.