-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Goals for Node.js and Package Manager Version Management Effort #597
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's missing the determinism.
Co-authored-by: Matteo Collina <matteo.collina@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we can make this much simpler:
- Define, run, and install the correct node version and package manager version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps “specific”?
- Define, run, and install a specific node version and package manager version globally or for a specific working directory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replacing "project" with "working directory" SGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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? |
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. |
Looks good from my perspective. |
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) |
Or I can link to #591 which should provide sufficient background |
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. |
A draft of the goals discussed in #595.
cc @nodejs/package-maintenance @nodejs/tsc