Update to Node 14

[LJNeon]

Eris currently has a minimum supported version of Node 10. However that version was released in 2018, isn't maintained anymore, and doesn't receive security patches. With Node 16 entering LTS in less than 3 months, I believe we should bump the minimum supported version to at least Node 14.

Updating to Node 14 brings countless security and performance improvements (especially to JSON parsing), bug fixes, and useful new features such as:

• Numeric separators to increase the readability of numbers.
• Optional chaining and nullish coalescing which allow for significantly simpler code when dealing with nullish values.
• Private class fields which are particularly useful for a library, as they make it easier to hide internal code that isn't meant to be exposed to users.
• ECMAScript modules have been stabilized. This removes the need to support unstable ESM versions in the package.json file.

I am willing to make a PR for this, however it's practically guaranteed to be full of merge conflicts with any existing PRs due to these new features. Because of that, I believe it would be better to wait until after the next Eris release to open such a PR, as merge conflicts will be at their lowest then.

[abalabahaha]

• Security and performance: IMO alone, this isn't enough reason, unless the Node version seriously breaks the lib (AFAIK not the case for Node 10 + Eris). The user is free to use whatever Node version Eris runs on. If the user needs/wants an older Node version and is willing to forego recent security and performance improvements, it's not the job of a Discord library to convince them otherwise.
• Nicer code: is a better reason, sure

I'm fine with new commits targeting minimum active LTS (currently Node 14), and then backporting big fixes to maintenace LTS versions (currently Node 12).

[bsian03]

Sounds like something for a new branch

[abalabahaha]

As said in OP,

I believe it would be better to wait until after the next Eris release to open such a PR

Also the next lib update has a bunch of features and I think everything already runs fine on Node 10, I'd rather nobody go out of their way to break compatibility.

that sounds like an overcomplicated mess

We already have version branches (e.g. 0.14.x) that get occasional backports. Changing supported Node version would be semver bump, so same thing.

[HarbingerNight]

It should be noted that erlpack isn't even capable of compiling w/ Node 16 support.

[DonovanDMC]

It should be noted that erlpack isn't even capable of compiling w/ Node 16 support.

We wouldn't be going to v16 for a long while, and losing erlpack isn't really that bad of a loss

[GoldenAngel2]

It supports node 16, the pr for it got merged: discord/erlpack#41

[retraigo]

This could be a good first step towards moving from CJS to ESM. ES Modules have a number of advantages over the current CommonJS, mainly the following:

• Named exports. These have already been resolved through the esm.mjs file so I'ma ignore this.
• Async loading. ES Modules are loaded asynchronously compared to CommonJS' synchronous loading with require(). More speed is good speed.
• Top-level await. Since ES Modules load asynchronously, they allow you to use await at the top level of the module.

However, these would be severely breaking changes due to the inability of CommonJS projects to load ES Modules. Therefore, these changes can definitely not be made without a warning. But they're a change certainly worth considering.

[DonovanDMC]

Considering how insane abal is about backwards compatibility, I seriously doubt eris will ever go full esm for the exact stated reason at the bottom - I'd take a good bet eris would lose a LOT of its userbase to a change like that

and unless there's something different about it.. commonjs can do named exports?

// 1.js
module.exports.whatever = "hi";

// 2.js
const { whatever } = require("./1");
console.log(whatever); // hi

[retraigo]

CJS exports are... One single object. There is one object exported and that is module.exports. Any extra named export you make goes into module.exports.

ESM exports are different. The default export and the named exports have nothing to do with each other.

export {no, strangers, to, love, know, the, rules}
export default {
    were: {
        no,
        strangers,
        to,
        love,
    },
    you: {
        know,
        the,
        rules,
    }
}

The two export statements do not interfere with each other. They're exported like,

{
    ...namedExports,
    default
}

import x from 'this file';
// you get that giant object from `default`

import {strangers, love} from 'this file';
// you directly get the two from the named exports.

The main advantage is being able to export whatever you want at the top level for users to directly import them.

Tho yea I do agree that going full ESM suddenly would just crumble the userbase. However, a lot of popular small modules are already going full ESM. A good example would be node-fetch. A complete change is just in the near future. I ain't asking to just suddenly move to ESM. I'm just asking to keep it in the plans moving forward.

The main reason a lot of people give for not switching over is "Typescript and Electron do not support ESM yet". When the large modules like these make the move, it'll just be a matter of time before the majority start using ESM.

[eritbh]

I don't think anyone is debating that CJS and ESM are structured differently. However, like you said in your first comment, Eris already has explicit support for ESM consumers by providing an ESM entry point that uses named exports. The distinction between the default export and named exports in ESM is unlikely to matter to internal code, since I don't think we have any file (other than the main entry point) where a non-trivial default export is used at the same time as named exports.

Similarly, top-level await isn't an advantage to Eris internally because the library has no need for it. Consumers of the library can already take advantage of that feature by importing Eris into an ESM context themselves. The only distinct advantage to be gained by refactoring Eris's own code to ESM would be any performance gained by the new module loading system, and for the vast majority of cases where Eris is loaded once on process startup, that seems unlikely to have real-world impacts to users either. So stable ESM support doesn't seem like a reason to drop support for older versions of Node on its own.

[elenakrittik]

Node.js released v20 recently. Abal, are you really sure there is a reason to support v10? It reached EOL whole 2 years ago, and v14 reached EOL recently too. If you care about your userbase, then simply make a poll asking what nodejs version people use. I'm pretty sure there won't be much answers below v14.

[abalabahaha]

are you really sure there is a reason to support v10? It reached EOL whole 2 years ago.

@ItsAleph that comment is also from over 1.5 years ago. If you update the numbers, the general sentiment of the comment still stands.