Goals for Node.js and Package Manager Version Management Effort

[GeoffreyBooth]

A draft of the goals discussed in #595.

cc @nodejs/package-maintenance @nodejs/tsc

[mcollina]

I think it's missing the determinism.

[mhdawson]

LGTM

[styfle]

Suggested change

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

[styfle]

I wonder if we can make this much simpler:

• Define, run, and install the correct node version and package manager version

[GeoffreyBooth]

Well 'correct' only makes sense in the context of a project, right? But users might also want to install Node onto their machine generally, before creating any projects or without any particular project in mind.

[styfle]

Perhaps “specific”?

• Define, run, and install a specific node version and package manager version globally or for a specific working directory

[wesleytodd]

Yeah we for sure want to be as simple and concise as possible, but the three we came up with proposed here attempted to disambiguate more than your proposed single line. The problem is we want to propose specific "product requirements" (as shown in "big doc proposal") but those overlap here. TBQH, I would rather land these if folks understand they are a stepping stone and can be evolved as we go forward (remember this is just a PR to the WG not a TSC agenda item or a new doc in the node core repo). If these are generally good IMO we just land them so we can all move on to the more important product requirements where we can bikeshed with more concrete topics.

[wesleytodd]

Ah interesting point, yeah agreed we want to avoid assumptions. Should we list out "application or library" or do you have a particular assumption you think folks mean which we want to avoid folks making?

[aduh95]

Replacing "project" with "working directory" SGTM

[GeoffreyBooth]

I don’t think “working directory” makes sense. If I’m in app/routes and I have an app/package.json, it’s the package.json root that defines the project scope; I shouldn’t need another app/routes/package.json to repeat the version of Node to use for commands in app/routes. I know we might not define configuration based on package.json, but I also think it’s unlikely that we would want to define it separately in every folder within a project.

[aduh95]

Saying "Define the correct Node.js runtime version and package manager version for the current working directory" says nothing about having the config file in the same directory, it could be in a different one (the parent directory in your example)

[GeoffreyBooth]

It implies that the unit we’re concerned with is the directory, when really what we’re focusing on is projects. Our goal here is to help users run the right software for their projects.

[joyeecheung]

I am not sure if this is the right place to ask, but I was struggling to find the right repo for this by googling and then I realized it is in the package maintenance working group and the README of this repo seems to have nothing to do with corepack or version management....or at least, we are talking about developing new features or new tools here, not talking about how to keep dead/old packages alive?

[GeoffreyBooth]

we are talking about developing new features or new tools here, not talking about how to keep dead/old packages alive?

Yeah, in the chartering discussion we wondered if perhaps it would be good to rename this team or start a new one. There’s a defunct @nodejs/version-management team too. I think for now the consensus was to deal with the goals first and then possibly rename/redefine the team based on what goals end up getting approved.

[nullivex]

Looks good from my perspective.

[joyeecheung]

Should I link to this PR in the trip report of the summit, or this repo? (somewhat weird to link to the repo while the REAMD still talks about package maintenance, but I guess we can also update the blog post)

[joyeecheung]

Or I can link to #591 which should provide sufficient background

[wesleytodd]

I wouldn't worry too much about the name. This group has always been a place to discuss ancillary tooling including package manager related topics. With this pivot we do need updates to the README, but as @GeoffreyBooth said we discussed chartering first and decided to establish the goals before chartering and changing the makeup of this group.