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

Node.js@nodejs.org

Reminder: Node.js v20 is end-of-life (EOL) today. Upgrade + get security support for EOL versions here: https://nodejs.org/en/about/eol

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?

I'm not sure how that fits with your original post, but I am in favour of dropping support for versions in a patch as soon as they're EOL. We should probably do that for Astro.

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

> specify the version of <engine> that your stuff works on that’s how we use it but that is a descriptive statement and i don’t see how changing it is a breaking change particularly when we are very clear that we expect nuxt users to stay on maintained versions of node

Unfortunately, for too long the ecosystem has thought of `node` as this implicit peer dep that will always exist. Specifying `engines.node` effectively codifies this peer dep relationship (historically unmanaged) & tools (like package managers) are going to warn/error when there's conflicts.