Repository navigation
Update node namespace values in package support #517
Description
Hey!
For a project, I was trying to implement the node namespace values. I took some notes as I was exploring it, which you can find raw here. However, I'd like to refine them and share my issues/concerns with the node namespace values:
- Currently, there is inconsistency in how the values are named.
ltsis equivalent tolts_allif we're looking at the naming of bothallandlts_latest/lts_active. We have two naming schemes side by side - effectively, we've implemented both a flat structure and a tiered structure, and the intersection of those two is messy.
activeis particularly problematic since it co-opts existing terminology.Activeis terminology already adopted by the release working group for LTS releases.activein the context of this includes both (Release WG terminology)currentandactive LTS, which does not help clarify the already confusing state that we exist within.
- Certain matrix combinations are missing.
- Example: there's not a way for someone to say they only support maintenance LTS.
- Example: there's not a way for someone to say they only support EOL versions.
- While these examples may not be something we'd immediately consider as valid options, there are potentially scenarios where they'd be useful. For example, imagine a polyfill library that backfills all possible new Node.js features to maintenance mode LTS, or a package that intentionally logs a message on EOL verisons.
Rather than building out an incomplete structure (especially when we've collectively consistently struggled with naming release concepts in the past!) as a matrix, I'd like to propose that we simply take the elements of the matrix and directly support those as an array rather than a string.
- current
- lts/latest (alternate:
lts-latest) - lts/active (alternate:
lts-active) - lts/maintenance ((alternate:
lts-maintenance) - eol
any combination of these achieves every option in the existing namespace:
- all:
current, lts/active, lts/maintenance, eol - lts:
lts/active, lts/maintenance - lts_latest:
lts/latest - supported:
current, lts/active, lts/maintenance - current:
current
additionally, some combinations not currently covered by the existing namespace are covered:
- ones people might actually use:
- lts/maintenance
- eol
- handful of others, but I can't imagine people using them.
the only variation from the Release WG definition of release lines is lts/latest which is a subset that's independent of categories, rather than a combination of multiple categories.
Activity
bnb commentedon Mar 11, 2022
I've published a module that accomplishes providing full information (whereas nv only currently implements a partial dataset) of the proposed properties, in addition to some additional useful information: http://npm.im/@nodevu/ranges
mhdawson commentedon Apr 26, 2022
Thanks for brining this up in the Package maintenance meeting today. It helped me understand some of the issues discussion. I think a PR to https://github.com/nodejs/package-maintenance/blob/main/docs/PACKAGE-SUPPORT.md and along with making sure we get feedback from @dominykas and @ljharb and then an plan for updating https://github.com/pkgjs/support. I'm hopeful that with aliases we could smooth the change for any existing people who have added the support info and the idea of an update command in the support package to help with that could be part of that.
bnb commentedon Sep 18, 2023
I would like to pick this up again, if possible. @mhdawson, @ljharb, and @dominykas - any objection to a PR to Package Support?
ljharb commentedon Sep 18, 2023
Seems good. A bit annoying for me personally that I'd have to explicitly list out multiple things to cover "all", but it's fine.
mhdawson commentedon Sep 19, 2023
@bnb I think a PR is the next step and any issue can be discussed there.
wesleytodd commentedon Sep 23, 2023
@bnb I feel like we talked about this before, but any interest in collaborating on
@pkgjs/nv? We are using it pretty heavily at netflix, and I don't know if I see a reason to have a tool outside of the Node project because if the build or release team changes any of the metadata, a owned and maintained tool to access it is quite a bit better than having to look around for the other tools we would need to update.I had at one point started a conversation about building a better file with more information. I didn't have time to follow up on that, but if we had folks working in this area again we could do that together maybe. Also, I have not attachment to the implementation there, and would be happy to dig in on specific thing you implemented that are different.
Also, fully in support of an amended list. That list is just confusing sometimes lol.
wesleytodd commentedon Sep 23, 2023
I knew we had talked about this. I should have went to look at the issues before commenting. I remember making this pkgjs/nv#25 trying to make the same point and pulling together your issues so we could discuss them together.
bnb commentedon Oct 13, 2023
My apologies for the delay, I've been extremely busy with travel 🙃
Reasonable annoyance, I look at it as a form of explicit self-documentation - it makes what exactly is happening clearer for those who aren't as familiar with Node.js releases as you and I are.
Sounds good, I'll aim to work on this over the next two weeks.
The reason I started nodevu was that @pkgjs/nv was completely broken in some pretty extreme ways the first time I tried to use it for something very basic, and there was a reason why I was prevented from upstreaming - I don't remember what it was, but it was a non-starter. The issues linked from the issue you linked are a pretty good insight into some of the issues I immediately ran into, though.
IIRC part of my intent here was that nodevu could be brought within the Node.js project. A big part of nodevu is also that there's supplemental tooling within the repo for different needs from the data, which includes things like parsefiles that is a sub-library that does parsing of Node.js metadata files into more usable states (useful for other things!), and translate that IIRC was a result of @mhdawson's request for a translation layer between what currently exists and my proposal in this issue.
wesleytodd commentedon Oct 13, 2023
No worries ever, this stuff has been in progress for years now so what is a few weeks?
Would love to have known what those were, but at this point I don't think we need to worry too much.
FWIW, I think we can resolve all of those issues pretty easily with the existing tool. Maybe just need to dig into that a bit more with the code specifically.
Do you mean in
nodejsorpkgjs?I actually think we should work with the build team on these files. If we can generate them initially in the most usable format that is ideal. But I also don't see this as any problem to combine forces on in one repo (maybe a monorepo like mentioned).