-
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
misc: drop support for node 10 #11656
Conversation
93e2dbf
to
aa0e5c0
Compare
@@ -59,6 +59,10 @@ const DEFAULT_PROTOCOL_TIMEOUT = 30000; | |||
*/ | |||
|
|||
class Driver { | |||
online = true; | |||
// eslint-disable-next-line no-invalid-this | |||
fetcher = new Fetcher(this); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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?!
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alright
is this ready-ready @connorjclark? it feels almost like a WIP given the number of it's OK if this needs a step back to update some of our toolchain first |
There was a problem hiding this 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); |
There was a problem hiding this comment.
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); | ||
|
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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
:/
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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?
No, I didn't anticipate every tooling to fail (oops). I'll make it clear when it's ready. |
This reverts commit f45b270.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
package.json
Outdated
"typescript": "3.9.7" | ||
}, | ||
"dependencies": { | ||
"acorn-node": "^1.7.0", |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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
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)