Discuss `package.json` standardization and governance

[Ethan-Arrowood]

During the Open Source Summit NA, we heavily discussed the idea about standardizing/specifying package.json. This was in part due to interest from the WinterCG side of things; generally, how could we make it easier for other tools to adopt and support package.json for JavaScript project configuration?

I am personally looking for this groups expertise on the subjects of specification, open governance, and more as I work to try and create a solution for the above question.

[ljharb]

The most important thing to establish imo is "what are the current difficulties for other tools to adopt and support package.json for JS project configuration?". Is that laid out anywhere yet?

[Ethan-Arrowood]

I have an answer, I haven't written it down anywhere yet. I'm worried that sharing the problem without also offering some solutions will be not productive in an async format. That said, I'm confident that a problem exists.

What I'm mainly seeking to gain from this working group is guidance on standardization, specification, and governance processes.

Some loose questions we can try answering first include:

• What is the difference between using an open governance model and a standardization model?
• What is a good way to approach key stakeholders with this? (Good as in inclusive, productive, solution driven, non-accusatory, etc.)
• What, if any, intellectual property issues may we need to prepare for?
  • package.json is currently documented by multiple parties. npm's docs are unofficially considered the source of truth. Similarly with Node's additional documentation for properties such as exports.
  • Other tools also document package.json, such as Webpack's package exports section
  • Tools also have used package.json in the past for specifying configuration (Jest & ESLint)
  • Regardless of how we may actual solve specifying all of this stuff, what are some IP issues we need to be aware of?

This is all I can think of at the moment, but other's are welcome to add more questions if they'd like.

[ljharb]

My suggestion is to explicitly avoid discussing solutions of any kind until the problems are understood and agreed upon - discussing solutions prior to that, in my experience, is what's counterproductive.

[dtex]

Moddable's manifest.json might be a good case study for identifying "current difficulties." I can't say for sure that they looked at package.json and found it lacking. They may have just not been aware of it. That said, the host is quite different from what most of us are used to so it may prove to be a good litmus.

[Ethan-Arrowood]

@ljharb agreed, what I'm trying to say is that I don't expect this group to help with defining the problem itself, like answering "do we need to specify package.json or not". I'm looking for help in certain parts of that problem creation. Some aspects are also related to the solution.

Like I don't expect this group to tell me "you should create a standards body" or whatever. I'm expecting them to provide information and guidance what the pros and cons are between a standardization approach and a governance approach.

[ljharb]

Gotcha, makes sense.

[eemeli]

@Ethan-Arrowood:
Like I don't expect this group to tell me "you should create a standards body" or whatever. I'm expecting them to provide information and guidance what the pros and cons are between a standardization approach and a governance approach.

Could you clarify a bit what you would expect a "standardization approach" and a "governance approach" to look like? As I understand it, a standard can help you clarify what the world looks like just now, while governance gives you a framework for changing it. For something like package.json, I would expect both of these to be of interest.

[Ethan-Arrowood]

Standardize -> Create a specification for package.json within an existing standards body such as WHATWG, or W3C, or wherever else. Development of the specification must follow the bodies existing processes. All invested parties must join the standard body. Etc...

Governance -> Using Open Governance create an group that governs the specification and its development processes.

They both are very much of interest. Specification probably is a common denominator. Standardization/Governance is another that we might not go 100% on one way or another.

[Ethan-Arrowood]

Notes from meeting:

• IP is pressing concern. Must get buy in from all contributors
• Since npm is considered a major source of truth, we should reach out to them first and get their input
• Similarly, discuss with other stakeholders and get their buy in
  • Yarn, Pnpm, Node.js, Bun, Deno
• Get buy in using endorsement from OpenJS and WinterCG
• Get buy in using personalized outreach
• Next steps: create one-pager outlining problem to be shared publicly
  • Focus on user impact
• Host discussions and collaboration in a neutral place. Maybe CPC ?

[LeaVerou]

Some thoughts, in no particular order (mentioned in the call, but dumped here for posterity):

• One of the great benefits of standardizing package.json would also be to define explicit extension points, rather than the current "anything goes" situation, where tools just add their own keys to the root.
• Standardizing in an existing consortium such as W3C (as opposed to an ad hoc group) has several benefits, such as patent policy protections, and existing recognizability and respect from a variety of stakeholders.
• Even you determine it's too early for this work to be part of a WG, there are several more lightweight arrangements for standards being incubated, such as W3C community groups, and WICG.

[jorydotcom]

Per May 30 WG meeting, removing Agenda label - @Ethan-Arrowood @tobie re-add the label when you're ready to discuss the doc again!