^14.0.0 || ^16.0.0 || ^18.0.0 || ^20.0.0 might be safer, since we don't test on any odd-numbered versions (all of them EOL'd) at all, but that could be considered breaking, so 🤷

@boneskull Yes, my thinking is that this default range makes sense (also getting on top of language features added during supported maintenance LTSs):

^16.20 || ^18.16 || >=20

or even (requiring explicit support signalling for future major node versions)

^16.20 || ^18.16 || ^20

But as you say, breaking either way and I'm thinking it would be nice to push out Node 20 support in a non-breaking release and then follow up with breaking runtimes as the next step and see which runtime versions make sense to keep support for separate from this PR.