-
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
core(tsc): add tsc type checking to report #5195
Conversation
@@ -317,7 +317,7 @@ class Simulator { | |||
simulate(graph, options) { | |||
options = Object.assign({flexibleOrdering: false}, options); | |||
// initialize the necessary data containers | |||
this._flexibleOrdering = options.flexibleOrdering; | |||
this._flexibleOrdering = !!options.flexibleOrdering; |
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.
updated tsc was stricter here
@@ -15,15 +15,18 @@ | |||
"diagnostics": true | |||
}, | |||
"include": [ | |||
// TODO(bckenny): unnecessary workaround until https://github.com/Microsoft/TypeScript/issues/24062 | |||
"node_modules/@types/node/index.d.ts", |
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.
annoying, hopefully temporary issue where the compiler thinks that EventEmitter
has a duplicate identifier. Manually putting the node
types first fixes this for now.
@@ -4,8 +4,8 @@ | |||
* Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. | |||
*/ | |||
|
|||
import * as parseManifest from '../lighthouse-core/lib/manifest-parser.js'; | |||
import * as _LanternSimulator from '../lighthouse-core/lib/dependency-graph/simulator/simulator.js'; | |||
import parseManifest = require('../lighthouse-core/lib/manifest-parser.js'); |
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.
turns out we shouldn't be trying to import * as
a commonjs module like this (and it's broken in newer versions of the compiler), so switched to the proprietary import x = require('x.js')
(works only in typescript code)
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 just for commonjs cases where you're not using a declare module
? got a link to somewhere that has the offish word :)
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.
the offish word :)
Probably here in the handbook, but there's a better explanation of the reasoning here from one of the typescript engineers:
These are mostly equivalent, but
import *
has some restrictions thatimport ... = require
doesn't.import * as
creates an identifier that is a module object, emphasis on object. According to the ES6 spec, this object is never callable ornew
able - it only has properties.`
https://stackoverflow.com/a/35706271
In our case, it appears they also extend that to importing the type of the module's export, as our old way is broken with the more recent releases of typescript. In fact, he ends it with
In some runtime+transpilation environments this might happen to work anyway, but it might break at any point in the future without warning, which will make you sad.
:)
var PerformanceCategoryRenderer: typeof _PerformanceCategoryRenderer; | ||
var ReportRenderer: typeof _ReportRenderer; | ||
var ReportUIFeatures: typeof _ReportUIFeatures; | ||
var Util: typeof _Util; |
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.
these add these to the global context for all of our code, even though we only depend on them being global inside the renderer.
An alternative would be to make a second tsconfig.json
file just for the renderer and compile the main project and the renderer separately. Not sure if it matters right now (but it might be more of a pain to have two separate tsc
runs, don't know)
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.
WFM! 🔪 ❤️ ☠️ 🚧
reportCategories: Array<CategoryJSON>, | ||
categoryGroups: Object<string, GroupJSON>, | ||
configSettings: LH.Config.Settings, | ||
}} ReportJSON |
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.
it'd be nice to switch these to the @property
syntax later on so we get some actual syntax highlighting :)
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.
t'd be nice to switch these to the @Property syntax later on
agreed, though I'm hoping the majority of the use of these will become references to the LHR types :) (it was purely laziness that I didn't convert these...I can if it would be better)
@@ -4,8 +4,8 @@ | |||
* Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. | |||
*/ | |||
|
|||
import * as parseManifest from '../lighthouse-core/lib/manifest-parser.js'; | |||
import * as _LanternSimulator from '../lighthouse-core/lib/dependency-graph/simulator/simulator.js'; | |||
import parseManifest = require('../lighthouse-core/lib/manifest-parser.js'); |
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 just for commonjs cases where you're not using a declare module
? got a link to somewhere that has the offish word :)
This is super cool. :) What's your proposal for devtools integration? Currently we include the renderer as part of all front_end typechecking. |
I'd need to take a look at the type checking step. Either it could be externs for the limited API (LHR, the major renderer classes) or we could do a full tsickle build step + whatever else cause tsickle is pretty limited |
@paulirish yah? nah? |
let's get |
well I tried and couldn't get it working with master, let alone the new branch, so maybe not worth it 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.
lgtm
wooohoo we are free
I'll update to the tsc 2.9rc that was just released |
In the process of updating to the new
details
format, it became obvious that our details type hierarchy is wrong in a few ways in the report renderer, and it was difficult to track how just using Closure. This drops Closure and moves to use tsc for type checking.A minimum effort was made to update the code for the new checker (e.g. it still uses the old typedefs instead of using LHR types yet) since changes are still in progress and it'll require some more extensive surgery to get everything correct.
In order to use the typedefs across files I updated our version of tsc so we can use the new
/** @typedef {import('./report-renderer.js').GroupJSON} GroupJSON */
format so we can
a) not
require()
a file just for its types and (risk circularrequire
issues) andb) use typedefs across files
sorry for the PR size. On the plus side, it's almost all jsdoc changes :)