Repository navigation
Interest check: package maps #173
Description
Activity
I'm very open to aligning where possible or pursuing a complementary spec if there's appetite for it.
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.
Reacted by Jordan Harband and Izaak SchroederI 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.
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!
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.
Reacted by Owen BuckleyOf course, thanks, I appreciate the invite. I applied to present the proposal at the next meeting.
One question that came up was, in runtimes that support import maps, such as Deno, how would package maps work?
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.Reacted by Owen Buckley and Simon BengtssonI'd be interested in following this discussion, although I don't have very strong opinions myself.
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.
Of course, thanks, I appreciate the invite. I applied to present the proposal at the next meeting.
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.
Reacted by Maël NisonHey 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.
Hi folks,
I recently opened nodejs/node#62239, which implements a
--experimental-package-mapflag for Node.js. The short version: it lets runtimes resolve packages from a static JSON file instead of walkingnode_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/scopesstructure 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.