Post

reminder that @nuxt.com doesn’t commit to support specific versions of node - we commit to supporting active and maintenance node versions on a rolling basis 👉 practically that means we may bump a dependency that is incompatible with an eol node version in a patch

Do you drop support for Node majors in a patch?

it’s not ‘dropping’ support we just don’t ever support eol node versions

That wasn't my question. I'm not implying this is wrong, it's a genuine question. Was e.g. Node 20 supported last month and not this month?

yes, as of today node isn’t supported for any nuxt version, no matter what engines.node says (engines.node isn’t a promise of support, it’s descriptive. in nuxt’s case it is largely based on the requirements of our dependencies)

`engines` definitions are meant to "specify the version of <engine> that your stuff works on". You really shouldn't distribute a definition if you don't support it. That said, if you're trying to gate the engine requirements of your transitive deps from consumers then you should probably own that.

Surely it's a descriptive statement that you commit to being true? Like, you wouldn't use a feature that only exists in Node 24 and above or dependency that relies on it, but as of this week you would for features that only exist in Node 22. That to me is a supporting a particular version of Node.

As I said I think dropping support for EOL Node is good and I'd not do a major for it, but I think you're drawing a false distinction saying it doesn't count as supporting particular Node versions and isn't a breaking change.

maybe the best analogy i can draw is browserslist: ‘maintained node versions’ we aren’t committing to support a given version beyond eol this is a limitation in the expressiveness of engines.node, which i wish supported a string like ‘lts/-1’, like nvm