Skip to content
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

Closed
brendankenny opened this issue Nov 3, 2017 · 4 comments · Fixed by #4703
Closed

Move to Node 8 #3742

brendankenny opened this issue Nov 3, 2017 · 4 comments · Fixed by #4703
Assignees

Comments

@brendankenny
Copy link
Member

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 and Object.values (no more Object.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.

@wardpeet
Copy link
Collaborator

wardpeet commented Nov 3, 2017

I don't have anything against it. I can always get some babel transpilation going outside of this repo to still support node6

@patrickhulce
Copy link
Collaborator

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.

@paulirish
Copy link
Member

We need a twitter poll to evaluate our node versions customers.

@paulirish
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants