Node.js Test Matrix

[wesleytodd]

I would love to see a test matrix which is not dependent on engines. Not all packages need or want engines and I think having an option that just always tests in lts_latest or something like that would be nice. Basically implement the aliases and use nv to get them at runtime. Thoughts?

[ljharb]

What packages don’t need or want engines set?

[wesleytodd]

Me 🤷 . Maybe I am putting on my hat of "company internal package author" as well, so maybe in OSS we could say everyone. I guess I was just thinking that adopting this on a new package should not require a breaking change.

[ljharb]

I'd love to understand when, even in an internal company package, you wouldn't want to always specify an engines range without exception.

[wesleytodd]

When we have code that didn't have it before, is widely used, and we don't have any benefit to asking folks to add it. Either way, I am not sure this line of the conversation is meaningful for this issue. I think the issue is more that this means adding this package requires a major version bump for existing packages which don't have engines.

[ljharb]

That's true, and while it's an unfortunate cost, engines, like exports, is valuable enough imo that it's fine that it requires that breaking change. A package that omits engines technically can't ever drop support for anything that worked within that major line, even if it happens to be an ancient engine, and that's unlikely to be the desired support matrix.

[wesleytodd]

Agreed, I just usually value ease of adoption over technical correctness.

[dominykas]

How would you define the minimum version of Node.js that's supported (i.e. required in the matrix)?

[wesleytodd]

I was thinking just default back to active lts at the time of the run. And to be clear, I am not saying this is a recommendation for how to manage most OSS packages, but it is just an affordance for folks adopting this so that it does not require a semver major to use it.

[ljharb]

fwiw you can already use ljharb/actions/node/matrix and provide any semver range; i could easily make it support all the Package Support values as well if that’s desired.

(i want to make it default to use engines, but it doesn’t use it at all right now)

[wesleytodd]

I will look at that one, I was hoping to avoid having my own of those as well and hoped to use this directly. Is there a meaningful difference you have in yours which we could make here and all get on board with one setup?

EDIT: oh yeah yours has alot. I will have to compare, but I sort of like what you have in that repo, I will dig in more.

[ljharb]

I use ljharb/actions on all 400+ of my projects, so they're quite battle-tested :-)

[dominykas]

an affordance for folks adopting this so that it does not require a semver major to use it.

Yes, but then it's a semver major change for the user when the LTS version changes, because we'd drop it?

Unless we manage to record the "initial" version somewhere? (where?)

[wesleytodd]

I mean my ideal is that most users don't need to think much about it and the tools just do the right thing. I think the problem is usually getting agreement on what the right thing is. So in this case, I like what @ljharb is doing over what we are doing here just using engines.

I think my main thing about just using yours @ljharb is that the goal of this org was to help folks who might not know as much about what they should be doing to get setup. So I guess we could just say "use these" and point at your repo, but that sort of dilutes the power of this GH org being a central place we can point authors for tools and then collab on making them better.

[ljharb]

True enough - altho we could easily make an action here that just composes mine, and then the source of truth still remains here.

[wesleytodd]

Totally, I am not sure I care strongly one way or another just more that projects in this org have a bit of consistency and that ideally we can point folks to these projects as good examples.

[wesleytodd]

Between this thread and the one in pkgjs/create-pkg#8 we have established that I am the minority opinion here. The prevailing opinion is that we should recommend strongly that folks include engines, and not having an on-ramp where it is not necessary is not something we are interested in supporting.