-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move to Node 8 #3742
Comments
I don't have anything against it. I can always get some babel transpilation going outside of this repo to still support node6 |
Can't wait to do this 👏 I'm against moving to it without publishing a transpiled version or doing a major version bump though. Dropping 6 & 7 support moves us from ~80% ecosystem coverage to ~35% ecosystem coverage and doing it on a minor version bump would be a bad experience for those in the ~45% not yet moved over to latest LTS. |
We need a twitter poll to evaluate our node versions customers. |
The 🚪 is now open on async/await, obj.entries, obj.values and a few other things. plz read brendan's original comment above as I think the policy spelled out is purrfect. |
Node 8 has now hit LTS, so we should consider moving over to having that as the minimum supported version.
We're of course already forward compatible, so anyone wanting e.g. perf improvements from Node 8 and 9 can already run Lighthouse there and get the benefits. However the language improvements are significant. Namely:
async
/await
(maybe worth it for the clarity brought by this alone)Object.entries
andObject.values
(no moreObject.keys(obj).forEach(key => const value = obj[key];...
:)along with a few other nice things like object rest/spread,
String.padStart
,String.padEnd
, the exponentiation operator, etc.A mostly organic transition to async/await would probably be best, like we did when we moved to Node v6 and only really added destructuring where it made sense (of course) and where we had some other reason to touch code than just updating to new syntax. We have some tricky promise tricks we use at times and a mass migration could easily miss subtleties (though hopefully our tests won't). And promises and async/await play together nicely, so mixing them for the near future won't be much of an issue.
I'm personally very eager to move over, but it is worth noting that last time we waited until January after the October LTS switch to move up versions, so prudence might have us wait.
The text was updated successfully, but these errors were encountered: