Get rid of old Node versions support

[koshic]

According to https://github.com/nodejs/release#release-schedule, we have only 2 (3, when v21 will be released) active Node versions - 18 and 20, all other versions reached their EOL and don't supported officially.

I propose to support only active Node versions in esmock. It will allow us to reduce codebase by removing old hacks / workarounds (yeah, I mean isLT1612 and friends), and use modern APIs like https://nodejs.org/dist/latest-v20.x/docs/api/module.html#moduleisbuiltinmodulename.

Sure, it requires to release new major version 3.0.0. Users with old Node versions can continue using esmock 2.x.x.

[iambumblehead]

Some reasons to continue supporting older versions of node,

• Browsing some dependents listed by github indicates many projects still support node 14 and even node 12 https://github.com/iambumblehead/esmock/network/dependents
• As a user, I would prefer if the javascript ecosystem and platforms would slow down and stabilize, rather than continued rapid release and change.
• As a user, it is a feature that esmock can be used with older versions of node if needed,
• Dropping node 18 would bring great improvements to esmock sources, but dropping node 16 would only bring small improvements,
• esmock does not require much energy from me now, and supporting older versions of node is slightly inconvenient but not difficult. How many releases will esmock have over the next year or so? Maybe not so many.

I would like to think about this topic and maybe research what support policies other projects are using.

[koshic]

I would like to think about this topic and maybe research what support policies other projects are using.

Yeah, you can treat this issue as a trigger ) It's impossible to support all versions infinitely, so some policy is required to avoid manually decisions every new Node release.

And a few of my thoughts:

Browsing some dependents listed by github indicates many projects still support node 14 and even node 12

It's a very controversial argument, you know - because 'many projects drop node 14 support', as an example. Moreover, it's very hard to evaluate which Node version really supported (I mean regular testing, real use cases, etc.).

As a user, I would prefer if the javascript ecosystem and platforms would slow down and stabilize, rather than continued rapid release and change.

In fact, this is not applicable to ESM features - hooks API marked as 'release candidate' (not even stable!) only in Node 20.8.0. And because upcoming Node 21 will not be marked as LTS, ESM stabilization will be done only in Node 22.

[iambumblehead]

agreed and thanks for this discussion and reply

[iambumblehead]

Users with old Node versions can continue using esmock 2.x.x.

https://github.com/ai/nanoid/issues / 365 extra spaces to prevent github from linking this discussion there... nanoid supports cjs with an older major version and esm-only with newest version and many users are/were angered. I'm a huge nanoid fan btw.

Maybe we could consider publishing a legacy version of esmock under a different name, like eg "esmock-loader" so that npm and yarn do not nag users to upgrade to the "latest version".

If we did this, maybe it would be good to do when upstream support for node 18 is dropped. We could move current esmock sources to an esmock-loader repo, publish them, then leave those sources basically frozen. After that, we could drop "--loader" and other things from esmock completely.

What do you think @koshic?

[iambumblehead]

this is not related really but just sharing this one also https://github.com/cypress-io/cypress/issues / 22355#issuecomment-1261096063

[koshic]

Nice! Idea is the same - split legacy and modern code, just by a different way. So I totally agree )

BTW, lint-staged updated too:

PS just one question (offtopic...) - what is the reason to use nanoid (as extra dependency) when we have https://nodejs.org/dist/latest-v20.x/docs/api/crypto.html#cryptorandomuuidoptions?

[koshic]

this is not related really but just sharing this one also https://github.com/cypress-io/cypress/issues / 22355#issuecomment-1261096063

It's a common OSS problem - as a developer, you can freeze your setup and it will work fine for several years, or (if you want to use something new) you have to update all components time by time, and solve similar issues due to some components switched to the modern rails without any fallback.

That's why I'm very interested in ESM, nobody ask us when some new feature will be make ESM-only (freedom, right?). And we should be ready to react immediately. From my experience, it's better to adopt new technologies than wait for real problems. Price will be paid in any case, but with that approach we'll have more time.

[iambumblehead]

PS just one question (offtopic...) - what is the reason to use nanoid (as extra dependency) when we have https://nodejs.org/dist/latest-v20.x/docs/api/crypto.html#cryptorandomuuidoptions?

this is true. I mostly like the nanoid-way of very small high-quality packages