Update `node` namespace values in package support

[bnb]

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.
  • lts is equivalent to lts_all if we're looking at the naming of both all and lts_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.
• active is particularly problematic since it co-opts existing terminology.
  • Active is terminology already adopted by the release working group for LTS releases. active in the context of this includes both (Release WG terminology) current and active 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.

[bnb]

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]

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]

I would like to pick this up again, if possible. @mhdawson, @ljharb, and @dominykas - any objection to a PR to Package Support?

[ljharb]

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]

@bnb I think a PR is the next step and any issue can be discussed there.

[wesleytodd]

@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]

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]

My apologies for the delay, I've been extremely busy with travel 🙃

A bit annoying for me personally that I'd have to explicitly list out multiple things to cover "all", but it's fine.

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.

@bnb I think a PR is the next step and any issue can be discussed there.

Sounds good, I'll aim to work on this over the next two weeks.

but any interest in collaborating on @pkgjs/nv?

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]

My apologies for the delay,

No worries ever, this stuff has been in progress for years now so what is a few weeks?

some pretty extreme ways the first time I tried

Would love to have known what those were, but at this point I don't think we need to worry too much.

The issues linked from the issue you linked are a pretty good insight into some of the issues I immediately ran into, though.

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.

IIRC part of my intent here was that nodevu could be brought within the Node.js project.

Do you mean in nodejs or pkgjs?

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

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).