nitrojs / nitrojs/nitro

Resolve `npm:`/`jsr:` versions from the installed tree for Deno-based presets

Open
#4,618 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

pending triage
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:

  1. the trace only runs when nitro.options.node is true, and the presets that would want this (deno_deploy, bunny) set node: false. So the version resolution would need to be independent from the file-copying path
  2. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.