Evaluate supported Node versions #41

New Issue

Ghost · 2019-06-17T18:10:27Z

Ghost commented

2019-06-17 18:10:27 +00:00

When writing plugins on newer versions of node, the following is reported:

You're using node v10.16.0
Please write node-v6 compatible JavaScript (not Babel/ECMAScript) and test with node v6.

(ACME.js and Greenlock.js are widely deployed in enterprise node v6 environments. The few node v6 bugs in Buffer and Promise are hotfixed by ACME.js in just a few lines of code)

Do you have up to date usage statistics here? A lot of large packages have moved on from Node 6 because it's not supported at all anymore (ESLint for example), not even for security updates. As of 2018-04-30 it started maintenance, and then as of 2019-04-30, it was EOL and hasn't received an update since: https://github.com/nodejs/Release. I can understand supporting Node 8 still, but supporting Node 6 seems extraneous.

When writing plugins on newer versions of node, the following is reported: ```plain You're using node v10.16.0 Please write node-v6 compatible JavaScript (not Babel/ECMAScript) and test with node v6. (ACME.js and Greenlock.js are widely deployed in enterprise node v6 environments. The few node v6 bugs in Buffer and Promise are hotfixed by ACME.js in just a few lines of code) ``` Do you have up to date usage statistics here? A lot of large packages have moved on from Node 6 because it's not supported at all anymore (ESLint for example), not even for security updates. As of 2018-04-30 it started maintenance, and then as of 2019-04-30, it was EOL and hasn't received an update since: https://github.com/nodejs/Release. I can understand supporting Node 8 still, but supporting Node 6 seems extraneous.

coolaj86 commented

2019-07-11 00:32:52 +00:00

I thought I had responded to this, but I must have gotten distracted.

Node v6 was over 20% of few months ago. I need to update the database and query again to see what it looks like now.

Since all of the useful features of the language are usable in ES5.1 (updates to the string prototypes, Intl, etc), there's no reason not to use it.

And even if the percentage was really low I'd still prefer to stick to plain old JavaScript because it's a smaller language that's intuitively easier to read (any programmer from any language can read "function" and understand what's going on). I just don't see much value in syntax sugar - especially when looking "cool" makes it less accessible to the average person.

I thought I had responded to this, but I must have gotten distracted. Node v6 was over 20% of few months ago. I need to update the database and query again to see what it looks like now. Since all of the useful features of the language are usable in ES5.1 (updates to the string prototypes, Intl, etc), there's no reason not to use it. And even if the percentage was really low I'd still prefer to stick to plain old JavaScript because it's a smaller language that's intuitively easier to read (any programmer from any language can read "function" and understand what's going on). I just don't see much value in syntax sugar - especially when looking "cool" makes it less accessible to the average person.

Ghost commented

2019-07-13 15:53:58 +00:00

I completely understand the syntax concerns. ES2015+ has some new syntax and concepts that can be hide to digest on quick skimming of code. They're great features and I certainly use them a lot, but I understand the concern here. I'd argue that Node.js 8+ introduces useful features like async/await and asynchronous iterators but that's just my opinion. There are also tangible performance improvements with Node.js 10 vs Node.js 6, with some operations being nearly twice as fast, as well as memory improvements, resulting in faster cold starts. Node.js 12 has even more performance improvements too, and introduces TLS 1.3, which lots of APIs are now using, and should always be preferred over TLS 1.2 where possible for security reasons.

However, I feel like actively encouraging people to use an EOL Node.js version that no longer receives security updates is actually dangerous. It's only a matter of time before a severe vulnerability is found in Node.js 6 that won't be patched (officially - it's possible we'll see vendor specific patches, but that's unreliable at best). The Node.js team handle this really well with their LTS schedule but Node.js 6 has been EOL for months now, and Node.js 8 is even going EOL at the end of the year. AWS talked about this back in May and encouraged everyone to update to Node.js 10 for this very reason. As a side-note, NPM v3 (shipped with Node.js 6) also comes without any default package-lock.json support (not to mention many other security and performance improvements), which has become a staple in the JS ecosystem now to ensure package integrity, and versions. There's lots of discussion in the past about the benefits of lockfiles, so I won't get into that here.

In addition, it's a limitation when using third-party libraries too. The official Cloudflare module I use in acme-dns-01-cloudflare still supports Node.js 6 today, but when that's inevitably dropped in the future and I have to use Node 6, I can either write my own, or use an old version which potentially has bugs, issues, or isn't updated for API changes, causing further fragmentation.

It seems that the biggest concern here is stylistic, and having code be more accessible, which I can sympathize with. So, how about a different solution?

Rather than encouraging people to use a version of Node.js that's EOL, encourage the use of the latest LTS version (10 at time of writing), and then distribute and encourage the use of something like an ESLint config to "disable" syntax sugar that you feel is less accessible, resulting in plain old JavaScript. Airbnb's approach is similar - they actively discourage the use of iterators and generators for example, as well as any TC39 proposal that hasn't reached staged 3.

This would be a much more graceful way of handling these stylistic choices, without encouraging the use of dead and potentially vulnerable software versions.

I completely understand the syntax concerns. ES2015+ has some new syntax and concepts that can be hide to digest on quick skimming of code. They're great features and I certainly use them a lot, but I understand the concern here. I'd argue that Node.js 8+ introduces useful features like `async/await` and asynchronous iterators but that's just my opinion. There are also tangible [performance improvements](https://benchmarking.nodejs.org/) with Node.js 10 vs Node.js 6, with some operations being [nearly twice as fast](https://v8.dev/blog/v8-release-66), as well as memory improvements, resulting in faster cold starts. Node.js 12 has [even more performance improvements too](https://medium.com/@nodejs/introducing-node-js-12-76c41a1b3f3f), and introduces [TLS 1.3](https://www.cloudflare.com/learning/ssl/why-use-tls-1.3/), which lots of APIs are now using, and should always be preferred over TLS 1.2 where possible for security reasons. However, I feel like actively encouraging people to use an EOL Node.js version that no longer receives security updates is actually _dangerous_. It's only a matter of time before a severe vulnerability is found in Node.js 6 that won't be patched (officially - it's possible we'll see vendor specific patches, but that's unreliable at best). The Node.js team handle this really well with their [LTS schedule](https://github.com/nodejs/Release) but Node.js 6 has been EOL for months now, and Node.js 8 is even going EOL at the end of the year. AWS [talked about this](https://aws.amazon.com/blogs/developer/node-js-6-is-approaching-end-of-life-upgrade-your-aws-lambda-functions-to-the-node-js-10-lts/) back in May and encouraged everyone to update to Node.js 10 for this very reason. As a side-note, NPM v3 (shipped with Node.js 6) also comes without any default `package-lock.json` support (not to mention many other security and performance improvements), which has become a staple in the JS ecosystem now to ensure package integrity, and versions. There's lots of discussion in the past about the benefits of lockfiles, so I won't get into that here. In addition, it's a limitation when using third-party libraries too. The official [Cloudflare module](https://github.com/cloudflare/node-cloudflare) I use in [`acme-dns-01-cloudflare`](https://github.com/nodecraft/acme-dns-01-cloudflare) still supports Node.js 6 today, but when that's inevitably dropped in the future and I have to use Node 6, I can either write my own, or use an old version which potentially has bugs, issues, or isn't updated for API changes, causing further fragmentation. --- It seems that the biggest concern here is stylistic, and having code be more accessible, which I can sympathize with. So, how about a different solution? Rather than encouraging people to use a version of Node.js that's EOL, encourage the use of the latest LTS version (10 at time of writing), and then distribute and encourage the use of something like an ESLint config to "disable" syntax sugar that you feel is less accessible, resulting in plain old JavaScript. [Airbnb's approach](https://airbnb.io/javascript/) is similar - they actively discourage the use of iterators and generators for example, as well as any TC39 proposal that hasn't reached staged 3. This would be a much more graceful way of handling these stylistic choices, without encouraging the use of dead and potentially vulnerable software versions.

coolaj86 commented

2019-08-05 20:04:43 +00:00

You make an excellent, compelling, and logical case.

Would you like to make a PR with your proposed changes?

You make an excellent, compelling, and logical case. Would you like to make a PR with your proposed changes?

Ghost commented

2019-10-09 00:05:23 +00:00

Sorry for the delay on this. From the Indiegogo updates, it sounds like the updated releases of this will be moving towards more modern JavaScript, so I assume will require a newer Node version like 8/10?

coolaj86 commented

2019-10-09 01:14:55 +00:00

I was going to use async/await, but then I saw that browser support is still really poor and that bummed me out.

In general, I want to stay away from anything that increases complexity or code size (which is most things).

async/await adds a small amount of complexity (more edge cases to learn, non-intuitive application), but it definitely reduces code size and, when used judiciously, it can decrease complexity along other metrics.

I want to use eslint and webpack because they're so popular, but I'm also very much not okay with the idea that you run npm install in a repo of 100kb of code+dependencies and then, literally, a hundred megabytes (140mb total) of version-specific tooling also getting installed.

added 811 packages from 241 contributors and audited 5336 packages in 15.169s

NOT cool.

I'm more okay with putting in the instructions something like:

Want to help out? You can get started just by cloning the repo.

If you have enough bandwidth to be able to download eslint, it would be great if you ran npm install --save-dev eslint and ran eslint **/*.js before making your PR

It just blows my mind that they require you to install it per-package and npm still seems to download rather than caching... or its caching really sucks and takes a long time to unpack.

I've figured out to make it so that my packages don't break WebPack, but I haven't been able to figure out how to effectively use it for myself. I think I need rollup for what I want (turning browser-compatible CommonJS into BrowserJS).

But yeah, I'm okay raising the bar to Node v8.

I was going to use async/await, but then I saw that browser support is still really poor and that bummed me out. In general, I want to stay away from anything that increases complexity or code size (which is most things). `async`/`await` adds a small amount of complexity (more edge cases to learn, non-intuitive application), but it definitely reduces code size and, when used judiciously, it can decrease complexity along other metrics. I want to use `eslint` and `webpack` because they're so popular, but I'm also very much not okay with the idea that you run `npm install` in a repo of 100kb of code+dependencies and then, _literally_, a hundred megabytes (140mb total) of version-specific tooling also getting installed. > added 811 packages from 241 contributors and audited 5336 packages in 15.169s NOT cool. I'm more okay with putting in the instructions something like: > Want to help out? You can get started just by cloning the repo. > > If you have enough bandwidth to be able to download `eslint`, it would be great if you ran `npm install --save-dev eslint` and ran `eslint **/*.js` before making your PR It just blows my mind that they _require_ you to install it per-package and npm still seems to download rather than caching... or its caching really sucks and takes a long time to unpack. I've figured out to make it so that my packages don't _break_ WebPack, but I haven't been able to figure out how to effectively use it for myself. I think I need rollup for what I want (turning browser-compatible CommonJS into BrowserJS). But yeah, I'm okay raising the bar to Node v8.

coolaj86 commented

2019-10-09 01:20:03 +00:00

P.S. I'm all for things that can be polyfilled and don't break the language.

Small language + Large standard library = great

P.S. I'm all for things that can be polyfilled and don't break the language. Small language + Large standard library = great

Ghost commented

2019-10-09 02:11:20 +00:00

Yeah, I'm a huge fan of async/await. Browser support isn't terrible though if you ignore IE - the latest 3 versions of all major browsers have support. We most use it on the back-end so this isn't a huge concern to us honestly.

All of that results in a massive node_modules folder though, and hundreds of packages being installed as you mentioned. It's definitely crazy, but I think most of us have just come to accept this is the JS ecosystem nowadays unfortunately. The newer (5+) versions of npm do have caching, but they're definitely not super optimal.

I'm glad to hear Node 8 will be the new minimum version though. It's been great following the project updates so far - let me know if there's anything we can do to help! 👍

Yeah, I'm a huge fan of `async`/`await`. Browser support [isn't terrible though](https://caniuse.com/#feat=async-functions) if you ignore IE - the latest 3 versions of all major browsers have support. We most use it on the back-end so this isn't a huge concern to us honestly. All of that results in a massive `node_modules` folder though, and hundreds of packages being installed as you mentioned. It's definitely crazy, but I think most of us have just come to accept this is the JS ecosystem nowadays unfortunately. The newer (5+) versions of npm do have caching, but they're definitely not super optimal. I'm glad to hear Node 8 will be the new minimum version though. It's been great following the project updates so far - let me know if there's anything we can do to help! 👍

coolaj86 commented

2019-11-01 22:04:18 +00:00

Anything that has less than 99% marketshare I consider to be terrible.

If 700,000,000 people on the planet can't access your site... that's a lot. 70,000,000 on the other hand, meh. :)

Greenlock v3 is out

Just because I wanted to drop a bunch of code, I've dropped some features in old versions of node and I print a warning message to update to node v11.2 or greater.

And really before v10.2 or so too much was missing from the crypto lib.

While I do want to continue to support older versions, it's impractical to backport some features.

I even use async/await in some of the tests now. It helps keep them cleaner.

Anything that has less than 99% marketshare I consider to be terrible. If 700,000,000 people on the planet can't access your site... that's a lot. 70,000,000 on the other hand, meh. :) # Greenlock v3 is out Just because I wanted to drop a bunch of code, I've dropped some features in old versions of node and I print a warning message to update to node v11.2 or greater. And really before v10.2 or so too much was missing from the crypto lib. While I do want to continue to support older versions, it's impractical to backport some features. I even use async/await in some of the tests now. It helps keep them cleaner.

coolaj86 closed this issue

2019-11-01 22:04:18 +00:00

Sign in to join this conversation.

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coolaj86/greenlock.js-ARCHIVED#41