Skip to content
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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Apr 17, 2024
Merged

Goals for Node.js and Package Manager Version Management Effort #597

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
758bfbb
Goals for Node.js and Package Manager Version Management Effort
GeoffreyBooth Apr 10, 2024
74f379a
Update goals.md
GeoffreyBooth Apr 10, 2024
378f5a8
Update docs/version-management/goals.md
GeoffreyBooth Apr 10, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions docs/version-management/goals.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
# Goals for Node.js and Package Manager Version Management Effort

Help application developers to:

1. Define the correct Node.js runtime version and package manager version for projects.
GeoffreyBooth marked this conversation as resolved.
Show resolved Hide resolved
GeoffreyBooth marked this conversation as resolved.
Show resolved Hide resolved

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.
Comment on lines +5 to +9
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

@styfle styfle Apr 11, 2024 •
edited
Loading

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

Copy link
Member

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.

Copy link
Member

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?

Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

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)

Copy link
Member Author

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.