Introductory Thread

[Ethan-Arrowood]

This repo was created as a result of a desire to standardize and specify package.json. It seemed best for this to be a WinterCG effort. Just because it exists here doesn't mean all runtimes have to adopt it, but for those that want to use it, this is a place we can all iterate on it collectively

[fabiancook]

Would be good to see how package.json maps to an importmap.json file officially, even just conceptually, and to have a standardised way around how package.json drives the module resolution process. The two requirements are virtually the same problem from the module resolution process as far as I can see where the results can be added to an importmap.

I would be keen on taking in a package.json file and spitting out the already standard importmap, using https://github.com/virtualstate/impack/tree/main#import-maps, right now it start the bundling from after the resolution point for external modules.

[UlisesGascon]

We can start from this Npm documentation just to ensure that we don't break package publication process. Then we can iterate and improve it?

[wesleytodd]

Ideally we can find a good way for the different groups with a vested interest in a package.json spec to extend beyond what the spec covers. This would also enable this work to take small steps where there is clear agreement and ecosystems can still "adopt" the spec while also extending it for their specific needs.

Also, not that I expect many folks to disagree, but I think the outcome of this should be a JSON Schema tools can use to validate against.

EDIT: I have been thinking about this for a few days, and my comment below should be considered superseding this one. I no longer believe we should start with a goal of a json schema, instead we should focus on building an understanding of what goals we are trying to achieve with this work.

[UlisesGascon]

Based on the Slack discussion and the current thread. I believe that the first step can be to port the npm [email protected] to W3C Bikeshed and start discussing on that PR, so it will be easier to collect input and feedback from all of us.

I am happy to do the port. Once we are clear on the PR discussions, I can recycle #2 to include the Json Schema and the tests.

[Ethan-Arrowood]

Yes I think its well agreed now to start from npm docs. I want to also consider Node.js' and Webpack's additions to it. I'm going to be bringing this to the OpenJS Foundation's Standards WG session on May 16th.

[Ethan-Arrowood]

We should also focus on the spec first. Make sure its all in agreement, then create the json schema. The schema should not be generated, at least at first. And then we can start building additional tooling around that. I need to think some more about how we approach code-based tooling here. I don't want to bikeshed too much, but we have many competing runtimes involved here and relying too much on one could result in implicit bias forming. Maybe we strive to do things using another language like Rust or Python, or at least require the JS-based tooling being self-executable.

Don't read too much into this thought right now. Just wanted to say it before we start landing Node.js tooling without considering all options 😄

[wesleytodd]

One other thing we should do is go to the OpenJS Standards Group to talk through any pre-standardization setup we need to do to ensure the legal and process requirements are met. We will need to consider what IP claims preexist on the package.json file as it is today. Which might include being careful about importing npm's existing package.json stuff.

[Ethan-Arrowood]

Exactly right @wesleytodd

My goal is to have something to show the standards group when I attend that call so that everyone is on the same page for what we are creating here. Furthermore, the WinterCG is a W3C community group, we only publish "drafts". This doesn't provide any IP protection, but does lessen the seriousness of our documents. Essentially, less is at stake when we "publish".

[rmarkins-godaddy]

@wesleytodd besides the Standards group this should definitely land insight of the package-maintenance WG to help champion in conjunction with WinterCG

[sheplu]

This is a great initiative but I do think we should also be discussing the scope of the change as this is quite wide

• are we talking about only Node.js or the "whole ecosystem" (in that case who / what ?). Is it only for runtimes or also some specific tools ?
• do we want to discuss about using package.json as a base for everything (and so have config available - not specific files for each tools)
• do we want to allow this usage by everyone and then any "keys" could be use (what about two projects using the same keys)
• I guess if that's the case we do have some reserved keys (runtime, engine, scripts, name, version...)

Speaking about it in a few days seems really fast and it seems to me good to define the scope / area of this initiative (that I supporte :) )

[wesleytodd]

Strongly agree that tightly scoping the conversation would help to avoid some areas where consensus cannot be had. So IMO the goal should be to start as small as possible on the technical focus, but as wide as possible on the community front. I don't think we should do any technical work to start and just work toward getting some folks from the important ecosystems into a conversation on what the goals of any shared package.json schema would help achieve.

[Ethan-Arrowood]

Agreed that this approach might not be correct. Nonetheless, it got us talking and thinking about it. No harm in eventually moving this conversation elsewhere either. I have ✨ thoughts ✨ i'm still thinking how I want to articulate. More soon 👍

[Ethan-Arrowood]

Update

Brought this initiative to the OpenJS Standards WG today. Gained a lot of great information. Most relevantly, we discussed where and how this works is going to get done. The WinterCG is a great option for hosting this collaboration as it is a neutral place for runtimes to collaborate. Considering this group is primarily focused on runtimes, we are considering operating from within the OpenJS Foundation instead. No official decision has been made just yet, but enable notifications for this issue if you'd like to receive future updates.

Thank you 🚀

[ljharb]

@Ethan-Arrowood if you need to transfer this repo, anyone who's an Admin on the repo and Owner in OpenJS can do it; if you need to, make me an admin and I can bounce it.

[Ethan-Arrowood]

Thank you @ljharb . I think we can leave this here, for now. Depending how next steps go we can consider moving it, or more likely we can just archive it and back link to this issue since its been the only piece of the repo worth keeping around.

[Ethan-Arrowood]

If folks are interested in the continuation of this work, please join us in the #package-json-discussion channel in the OpenJS Slack workspace.

[Ethan-Arrowood]

last week we determined a different direction for this work. We are going to focus on a bottom-up (standardizing pieces of package.json) approach rather than a top-down (standardizing all of package.json). Furthermore, with one of the major concerns being developer experience, we are going to simultaneously start trying to improve that by creating a research hub. This hub will be a collection of documentation (and potentially some high level summary) of all of the various package.json fields we see in the wild. I will be contributing the start of that research hub this week.

Additionally, it seems that this work is better hosted under the OpenJS umbrella. It is an even-more-neutral place, plus they have a greater level of organizational expertise to support the project. WinterCG also seems more like an active participant in this effort rather than its lead. I'll be archiving this channel for now. We can always unarchive it later if we determine some work better belongs under this organization.

Reminder to join us in the OpenJS Slack channel for latest updates on this effort