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

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.

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

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.

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

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

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.

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.

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