feat: next steps for version management progress

[wesleytodd]

A discussion was had in the OpenJS Slack about how to proceeded with next steps. This PR intends to represent what the folks in that thread think should be taken as next steps.

[ovflowd]

LGTM, this is inline with what I've advised.

[marco-ippolito]

Data from the latest survey, it seems corepack its pretty popular

[ovflowd]

Data from the latest survey, it seems corepack its pretty popular

It is indeed! I use it regularly too. We all love Corepack (or at least I do), I think that was never the question 🙈

[ljharb]

Are we assuming tho that 2000 people can accurately represent the number of actual node users?

[marco-ippolito]

Are we assuming tho that 2000 people can accurately represent the number of actual node users?

I'm just displaying data that was gathered through an official survey, if you think the result is not relevant I guess there are other actions to take on the utility of the survey itself

[wesleytodd]

Lets not make another massive thread of conflict here please. I am catching up on the above, but the goal here is to reset a bit, can we all try to come at this with fresh eyes?

We have goals already listed, and @aduh95 is right that "let corepack evolve independently" was not on them and we are trying to reach consensus including with @aduh95. And we are trying to do the above without having to resort to TSC involvement again until we have an internal consensus. Lastly, having data (even if it is low volume data) is better than not having data.

So all that being said, if this is going to turn into a repeat of previous threads I am going to start hiding replies and taking a heavier hand on the direction of the conversation here.

[wesleytodd]

The outcome from our discussion on the call today is this:

1. We are going to adapt point 4 into a few additional steps around stages of changing our recommendation and some goals to meet at each
2. We will recommend locking the PRs and direct folks to this group for further discussion on these topics to prevent additional swirl in the ecosystem
3. We need one or more champion for Corepack to help drive this conversation. If we need to adjust meeting times or discussion forums we can do that to make it happen.

Anyone else have anything which was an action item I missed?

[mcollina]

lgtm

[wesleytodd]

Ok, I (finally) pushed some amendments based on our previous conversations. It is not exactly the feedback I got from @aduh95 or @ruyadorno but I think I captured the spirit of our conversations. Feedback welcome!

[mcollina]

@anonrig please open a separate issue to discuss the governance of the project (in admin or tsc). What you are asking is outside of our charter for a lot of reasons.

---

On the topic:

I haven't had any chance/time to attend any of the meetings, but I don't think this decision is beneficial for the common good of the community. Removing a highly used feature is almost always result in backlash.

My take is that solving nodejs/corepack#495 will require a redesign of corepack, almost from scratch. So far, no one has been willing to address the problem, and there has been a light push back on it.

(I personally have no time for it, but I'll be ok in a brainstorming session and reviewing a design document for such a redesign).

The security implications of nodejs/corepack#495 alone would not be enough to justify removal (even if it's an experimental feature), but combined with the lack of volunteers/pushback to do the required work, I see no other path forward.

As @targos once said: corepack could be what we want. Despite bing a popular feature, and many tweets, blog posts and videos discussing this, I see no volunteers to do the work needed: and most people commenting on this have the skills to participate.

What you are asking is for the TSC to take on the maintenance of corepack, and the answer is (likely) a "no". No one can force a volunteer to do what they don't want to do.

[wesleytodd]

The goal of this was to work toward a proposal which could reach consensus. @anonrig I think a bunch of your comments are valid and relevant, but it appears they have caused this discussion to spiral out of control again. I said it above and I mean it, please dont make this a thread where I have to start hiding comments (thanks to whoever did it with the ones above, that was exactly the kind of thing I was worried about). If folks want to argue please come to our meetings or join us in the slack discussions. This PR is not a vote, landing this PR does not constitute a decision by the TSC to take a specific action, and so a blocking review on it does nothing of consequence.

We have a governing body to make the final decision about any discrepancies.

With the above being said, the TSC has failed multiple times to reach a consensus. The whole point here is to push it back OUT of the voting realm until there is a vote which actually has a chance of success. If you disagree with that approach, I am not sure how to convince you, but it staying in limbo with compeeting PRs to enable and remove it entirely is not healthy for the project, community, or the TSC itself.

And lastly, that governing body TOOK A VOTE (edit: had a discussion, it was not a vote, my apologies. Thanks @aduh95 for pointing that out to me) to decide to give this group the authority to make a recommendation after a proper community discussion. That is what resulted in this PR. So if we could bring it back (or as @mcollina said, open a different issue to discuss other governance issues) to the topic of this PR that would be great.

There is a pending/draft TSC voting about corepack which is still alive.

One of our discussed recommendations (which did not get included in the PR content) above was that we close all lock all these for now until we can sort our a consensus recommendation here. Do you think I need to add that to the text of this PR?

#606 (comment)

I genuinely don't know what should be done then if there's a -1 on this PR. Should another vote happen?

No, working groups do not have votes like this afaik. We work toward consensus or we decide to abandon the recommendation. So if @anonrig wants to join the group and help us refine this until there is consensus that would be awesome, if not I don't think we are ready to kick it back up to another ill fated TSC vote.

---

@Spitfire1900 I hid your comment as off topic. Sorry, but please we are not seeking recommendations like this at this time. We would be happy to hear this feedback in a separate issue or in one of our meetings as I think it is great feedback. We just need to be ruthless in keeping this discussion on track because of how often it has went off into the weeds.

Similarly I hid the discussions with @anonrig and @ljharb about the unrelated proposed governance issues.

---

In closing, I would love if we could get feedback on the goals we stated. If you disagree with those goals, that would be good to hear because this proposal is just a continuation of achieving those goals.

[lukaselmer]

@wesleytodd

In closing, I would love if we could get feedback on the goals we stated. If you disagree with those goals, that would be good to hear because this proposal is just a continuation of achieving those goals.

IMO the goals are a great start. Maybe they need to be clearer.

Define the correct Node.js runtime version and package manager version for projects.

This means that the package manager and the version of the package manager can be specified, right? Not only the version of npm 😏

Install Node.js and a package manager for a local development environment.
Run the correct version of Node.js and of a package manager for each project.

From these two points, I'm missing that this should be as easy as possible, and mostly (fully?) automated. A website/manual with instructions is not good enough.

[wesleytodd]

Maybe they need to be clearer.

Happy to have more input on them. If you have concrete feedback please open an issue or even a PR with your suggestions.

I will address these here to keep the convo together, but ideally we can keep the two conversations focused on their respective parts going forward.

This means that the package manager and the version of the package manager can be specified, right? Not only the version of npm

Yes exactly. That is one of the major sticking points when it comes to applications (vs libraries) where corepack does not cover the needs. App authors need their teams to use both the correct package manager and node version to align with what will ship to their production servers. This could mean we recommend two tools (corepack and nvm for example`) or we could seek alternatives with less tooling (install both as dev deps, for example). Either way, the recommendation from the Node project should not be incomplete if we can help it.

I'm missing that this should be as easy as possible, and mostly (fully?) automated. A website/manual with instructions is not good enough.

I think there are competing concerns here, but yes I agree. Some people have made strong arguments that in many cases you dont want accidental mistakes because of too much automated things. We wrote those goals to try and take a softer stance at first to keep progress moving, but IMO the end goal is to recommend tooling which can scale the automation to the end users liking. This likely means we need:

1. A fully automated setup which users can opt into specifically not on by default to prevent problematic security concerns from arising
2. An automated setup with interactive opt in (most like corepack enable today imo)
3. A manual mode

This is my personal take, but my main goal is that we should support all the required environment concerns (node, package manager, maybe more?) in a consistent UX based on your preferred level of automation.

[ovflowd]

@anonrig are you willing to change your "request for changes" to approval, given what @wesleytodd mentioned?

[wesleytodd]

Awesome. We have addressed all the concrete feedback. Thanks everyone who is helping move this conversation forward, your great work is very helpful.