Outdated Node.js version support

[LJNeon]

This is based on travis coverage, as I couldn't find a better indicator of supported versions (such as "engines" in package.json).
Node 8, 11, and 13 are no longer maintained and shouldn't be supported, and Node 14 is missing support. ESM is also unflagged in Node 14, and backwards-compatible support is relatively easy if you're willing to add some ease-of-use.

[iarna]

Unpopular opinion: Because a version of node is unmaintained doesn't mean modules shouldn't support them.

Second unpopular opinion: I avoid ESM whenever possible.

That said:

11 and 13 should definitely come off the list. I don't currently have any reason to stop supporting 8. But I'll consider it. (I only drop support for versions when doing major releases. IMO, Node support drops should never happen on bugfix or minor version bumps.)

I would accept a patch to provide compatible mixed ESM/CJS mode if you can do that without introducing a build step. That is, consumers on Node 10 need to be able to continue to use the module without changing their code.

[LJNeon]

I happen to disagree with both of those opinions, however they are far more popular than you seem to think. And yea, odd number releases aren't meant for long-term support or usage. The main problem is that there have been several major security vulnerabilities patched since Node 8 left maintenance mode. At least personally I feel that supporting it is promoting lazy devs who don't want to update dead Node versions, leaving services vulnerable.

As for mixed ESM/CJS support, this is far easier than you seem to think. You can achieve it by simply creating a wrapper file that re-exports your CJS files as ESM. I believe this would be the entire wrapper file, it just needs a .mjs file extension:

export {default as parse} from "./parse.js";
export {default as stringify} from "./stringify.js";

Then you simply need to indicate support in your package.json file, by adding something like this (toml-esm.mjs being the wrapper file):

"main": "./toml.js",
"exports": {
  ".": [
    {"require": "./toml.js", "import": "./toml-esm.mjs"},
    "./toml.js"
  ],
  "./esm": "./toml-esm.mjs"
}

Node 14+

• CommonJS works
• ECMAScript works, backwards compatibility (for import "@iarna/toml/esm") exists.

Node 13

• CommonJS works
• ECMAScript works with either a path OR a flag (--experimental-conditional-exports)

Node 12

• CommonJS works
• ECMAScript works with a path (import "@iarna/toml/esm") AND a flag (--experimental-modules)

Node 8 and 10 (and many lower versions, although those aren't relevant)

• CommonJS works
• ECMAScript doesn't work

[LJNeon]

If you would rather not support highly experimental versions of ESM that require a flag (so Node 12 and 13), you can simply remove the "./esm": "./toml-esm.mjs" line from package.json.

[iarna]

If you could phrase this as a PR? =D (If you're not up to this, I'll do it myself, but it'll get in faster this way. XD)

As far as older versions go: I'm not about supporting lazy devs, I'm about supporting overworked ops teams. The reality is that all of security is constant cost/benefit calculations, and the risk level of a given vulnerability is going to vary a lot depending on the specifics of the situation. Folks tend to think in terms of Node backing up websites, but I know of a number of very large Node installations that are not web based at all.

[jsejcksn]

Second unpopular opinion: I avoid ESM whenever possible.

@iarna Will you explain this? I'm very interested to understand your perspective. If you've already written about it elsewhere, a link is great.