Resolve `npm:`/`jsr:` versions from the installed tree for Deno-based presets
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 11.2k
- Forks
- 899
- Avg merge
- 2d 24m
- Merged PRs (30d)
- 40
Description
Describe the feature
While fixing something on the Bunny preset (#4025) I've made the Deno-based presets keep npm: and jsr: specifiers external, so import { escape } from "npm:lodash-es@4.17.21" survives the bundle and gets resolved by the runtime instead of failing to resolve at build time.
That part works, but pinning the version is currently entirely on the user. What I would actually like is to mark a package as external and have Nitro emit the version that is installed, so a plain import { decodeJwt } from "unjwt" comes out as npm:unjwt@0.7.2 even when package.json says ^0.7.0.
The clearest win is on Bunny, where the script is a single file with a 10MB cap, so keeping deps out of the bundle actually matters. Tho it would apply to deno_server and deno_deploy just as well, for custom implementations and runtimes.
Most of the machinery seems to already be there: nf3 hands us the exact resolved versions per package (TracedPackage.versions), and we already consume that hook in
externals.ts only to log them.
Two things I got stuck on though:
- the trace only runs when
nitro.options.nodeistrue, and the presets that would want this (deno_deploy,bunny) setnode: false. So the version resolution would need to be independent from the file-copying path - it only pins the direct dependency. Deno then resolves the transitive ones from the registry on its side, so it is a partial pin and not really a lockfile equivalent. I am not sure whether that is acceptable or if it defeats the point
I also have no strong opinion on the config surface, an opt-in list of packages feels right but that is about as far as I got.
Additional information
- Would you be willing to help implement this feature?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/build/plugins/externals.ts around the existing TracedPackage.versions logging and src/build/plugins.ts around the nitro.options.node check; compare how the deno_deploy and bunny presets configure these paths. Clarify the opt-in configuration and transitive-dependency behavior, then verify that installed direct versions are emitted for the relevant Deno presets.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- deno, typescript
- Domain
- backend, build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100