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

misc: drop support for node 10 #11656

Merged
merged 21 commits into from
Dec 2, 2020
Merged

misc: drop support for node 10 #11656

merged 21 commits into from
Dec 2, 2020

Conversation

connorjclark
Copy link
Collaborator

@connorjclark connorjclark commented Nov 11, 2020

Drops Node 10. Minimum support is now 12.

I added usage of a Node 12 feature, public instance fields. They are still stage 3, which means eslint's ecmascript parser doesn't support it, so I also changed the eslint parser.

(This is a breaking change–do not merge yet)

@connorjclark connorjclark requested a review from a team as a code owner November 11, 2020 21:35
@connorjclark connorjclark requested review from patrickhulce and removed request for a team November 11, 2020 21:35
@google-cla google-cla bot added the cla: yes label Nov 11, 2020
@@ -59,6 +59,10 @@ const DEFAULT_PROTOCOL_TIMEOUT = 30000;
*/

class Driver {
online = true;
// eslint-disable-next-line no-invalid-this
fetcher = new Fetcher(this);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is an error in babel-eslint parser. this is perfectly fine here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is an error in babel-eslint parser. this is perfectly fine here.

even if it's parsed correctly, I'd imagine eslint isn't going to have any "allow in field initializers" code until they add support for public fields.

(there's also a corner case to handle, where this works here unless the constructor ends up returning something else. hopefully we never land code like that in lighthouse, though :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do you mean a constructor can return something else?!

Copy link
Collaborator Author

@connorjclark connorjclark Nov 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wtf gross https://javascript.info/constructor-new#return-from-constructors

this seems sort of acceptable for functions used as a ctor, but does constructor() really allow this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wtf gross

haha yes, maybe there's some purity argument somewhere since every function is a potential constructor, but it's a bad argument :)

@@ -8,7 +8,7 @@
"chrome-debug": "./lighthouse-core/scripts/manual-chrome-launcher.js"
},
"engines": {
"node": ">=10.13"
"node": ">=12.13.0"
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be 12.0? Or should CI install 12.13.0?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I always get annoyed when packages pick an unnecessarily specific version, anything wrong with 12.x?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

12.13 was the first LTS version, so it seems ok to rely on that as a floor. OTOH I don't see much that was added between 12 and 12.13. Promise.allSettled, but anything else?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Promise.allSettled, but anything else

looks like yes, there were a few more things we'll be interested in, like the Intl.NumberFormat improvements (like 'unit') and the V8 7.6 and 7.7 releases. Doesn't seem too onerous to use the October 2019 release as a minimum?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alright

build/build-utils.js Outdated Show resolved Hide resolved
@patrickhulce
Copy link
Collaborator

is this ready-ready @connorjclark? it feels almost like a WIP given the number of Refresh prompts I had while reviewing 😉

it's OK if this needs a step back to update some of our toolchain first

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are still stage 3, which means eslint's ecmascript parser doesn't support it, so I also changed the eslint parser to babel-eslint.

It was only a few days ago I was saying in chat how much better parser: '@typescript-eslint/parser' is than babel-eslint :P

@@ -59,6 +59,10 @@ const DEFAULT_PROTOCOL_TIMEOUT = 30000;
*/

class Driver {
online = true;
// eslint-disable-next-line no-invalid-this
fetcher = new Fetcher(this);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is an error in babel-eslint parser. this is perfectly fine here.

even if it's parsed correctly, I'd imagine eslint isn't going to have any "allow in field initializers" code until they add support for public fields.

(there's also a corner case to handle, where this works here unless the constructor ends up returning something else. hopefully we never land code like that in lighthouse, though :)

online = true;
// eslint-disable-next-line no-invalid-this
fetcher = new Fetcher(this);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not move all the other fields at the same time? Can mark them as @private to sidestep the # question for now :)

Copy link
Collaborator Author

@connorjclark connorjclark Nov 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, but types fail now in the test file...
image

Thoughts? Drop the private marker?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts? Drop the private marker?

Ah, yeah, that's unfortunate. Of course in theory we shouldn't be touching private state for tests, but obviously that's often not possible or makes things worse. I guess no @private :/

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I marked it.... @pri_vate.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not move all the other fields at the same time?

too late now, but a good reason IMO would have been that it creates merge conflicts for in progress PRs and we only needed to do 1 small node 12 syntax feature for our v7 goals :)

@@ -8,7 +8,7 @@
"chrome-debug": "./lighthouse-core/scripts/manual-chrome-launcher.js"
},
"engines": {
"node": ">=10.13"
"node": ">=12.13.0"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

12.13 was the first LTS version, so it seems ok to rely on that as a floor. OTOH I don't see much that was added between 12 and 12.13. Promise.allSettled, but anything else?

@connorjclark
Copy link
Collaborator Author

is this ready-ready @connorjclark? it feels almost like a WIP given the number of Refresh prompts I had while reviewing 😉

it's OK if this needs a step back to update some of our toolchain first

No, I didn't anticipate every tooling to fail (oops). I'll make it clear when it's ready.

This reverts commit f45b270.
Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

lighthouse-core/scripts/dogfood-lhci.sh Outdated Show resolved Hide resolved
package.json Outdated
"typescript": "3.9.7"
},
"dependencies": {
"acorn-node": "^1.7.0",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this supposed to be a devDep?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ya! I was just about to do it earlier but then VSCode froze and I forgot. Has vscode been freezing for you lately? It's a new thing for me...last week, few times a day I get a 100% cpu usage

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm not really, are you using insiders too?

package.json Outdated
"@wardpeet/brfs": "2.1.0-0",
"acorn-node": "^1.7.0",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't need this explicitly, it's browserify's dep, just need to delete and have it regenerate in yarn.lock

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

Successfully merging this pull request may close these issues.

5 participants