Repository navigation
Interest check: package maps #173
Description
Hi folks,
I recently opened nodejs/node#62239, which implements a --experimental-package-map flag for Node.js. The short version: it lets runtimes resolve packages from a static JSON file instead of walking node_modules, giving package managers a standard way to express strict dependency boundaries and eliminate phantom dependencies.
The format is intentionally minimal - a flat map of package IDs to paths and allowed dependencies:
{
"packages": {
"my-app": {
"path": "./src",
"dependencies": {
"react": "react@19"
}
},
"react@19": {
"path": "./node_modules/react"
}
}
}During review, the question came up of whether this should go through a standards process so other runtimes can implement it too - rather than being a Node.js-only thing that others later have to play catch-up with.
I intentionally diverged from the import maps spec (the imports/scopes structure doesn't map well to the package-level semantics needed here), but I'm very open to aligning where possible or pursuing a complementary spec if there's appetite for it.
Would TC55 members be interested in discussing this? Happy to write up a more formal explainer or join a call if that's useful.
Activity
wesleytodd commentedon Mar 26, 2026
Personally this would be my preference. I think that we gain orders of magnitude more value building on top of existing specifications and showing how to incrementally improve, than deviating even when the logic for the deviation is sound.
Ethan-Arrowood commentedon Mar 31, 2026
I need to familiarize myself with the existing import maps spec before weighing in on that aspect. Otherwise, I agree that this seems like a valuable thing to go through some standardization.
Ethan-Arrowood commentedon Apr 3, 2026
Hey @arcanis & @wesleytodd 👋
We chatted briefly about this today on the call. Async discussion on this thread is totally fine, but in order to discuss this on a WinterTC call, you'll need to become Ecma delegates or invited experts. Alternatively, we can discuss things informally in the OpenJS Package Metadata Interoperability working group first. Let me know how I can help coordinate!
andreubotella commentedon Apr 16, 2026
We were discussing this some more in today's WinterTC call. If we were to define this in the spec, we might want to specify the behavior of package maps in terms of how they translate to import maps, so that we can use the HTML machinery for import maps.
One question that came up was, in runtimes that support import maps, such as Deno, how would package maps work? One possibility could be that if you have both, they would behave just like you had multiple import maps. Alternatively, a package map might disallow import maps. It'd be good to have feedback from Deno on this. cc @littledivy @devsnek
I'd also encourage @arcanis and @wesleytodd to become WinterTC delegates or invited experts so we can discuss this in the WinterTC calls in more detail with them involved.
arcanis commentedon Apr 16, 2026
Of course, thanks, I appreciate the invite. I applied to present the proposal at the next meeting.
The way Import Maps tend to be declared on a per-
deno.jsonbasis in Deno, similar to how theimportsfield in Node.js works, would tend to make me think of import maps as overriding package maps should they have overlapping paths.guybedford commentedon Apr 17, 2026
I'd be interested in following this discussion, although I don't have very strong opinions myself.
wesleytodd commentedon Apr 17, 2026
Sorry I have not had time for much OSS work lately. I can probably try and come to a future meeting though, so happy to do whatever you think is best to move the conversation along.
EDIT: I had some time while at the collab summit this week to put together a slightly better reply in nodejs/node#62239 (comment), it also specifically asks for how import maps and package maps would work together, but I really think that many of these things can be reconciled in an import map compatible form.
andreubotella commentedon Apr 17, 2026
For the record, in the next WinterTC meeting (see #182) we have to approve a new chair group as well as the Runtime Keys techical report, both of which are at least somewhat time sensitive, and we will likely have no time left for discussing this issue. The meeting after that should be May 15, and I'll try to make sure to add this issue as the first thing on the agenda.
arcanis commentedon May 30, 2026
Hey folks, it was nice meeting you all yesterday - here is the article I mentioned where I went into more details about differences between package maps and import maps!
@andreubotella I think the main action item discussed in the meeting was for me to look at how this proposal could be worded in a spec document; is there a particular tooling I should use? I was thinking to copy how the iter-streams proposal repo is structured.