-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
types: better types #1166
types: better types #1166
Conversation
@dgozman comments
|
|
export const chromium: import('./lib/server/chromium').Chromium; | ||
export const firefox: import('./lib/server/firefox').Firefox; | ||
export const webkit: import('./lib/server/webkit').WebKit; | ||
export const selectors: import('./lib/api').Selectors; |
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 about selectors, web, errors and devices?
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 web public right now? How is it accessed? I did the others.
@@ -30,9 +30,10 @@ | |||
"wcoverage": "cross-env COVERAGE=true BROWSER=webkit node test/test.js", | |||
"tsc": "tsc -p .", | |||
"clean": "rimraf lib", | |||
"build": "node utils/runWebpack.js --mode='development' && tsc -p .", | |||
"build": "node utils/runWebpack.js --mode='development' && tsc -p . && npm run generate-types", | |||
"watch": "node utils/runWebpack.js --mode='development' --watch --silent | tsc -w -p .", |
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.
Do we need something for watch?
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'm not sure. I don't think it works right now in build though. It depends on the protocol.ts file to be generated, but the protocol generator requires the project to be built. I'll move it to a separate command that runs on bots, test, and before publishing.
I think this is ready for another look! |
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.
Overall looks good. Could you please post a gist with generated types?
utils/generate_types/overrides.d.ts
Outdated
type ElementHandleForTag<K extends keyof HTMLElementTagNameMap> = ElementHandle<HTMLElementTagNameMap[K]>; | ||
|
||
type WaitForSelectorOptionsNotHidden = PageWaitForSelectorOptions & { | ||
visibility: 'visible'|'any'; |
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.
This has been changed recently.
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.
Unfortunately my tests for this didn't catch it somehow. I don't know how to make them more strict, but I fixed it.
|
Currently in our API `?` means null, but sometimes it means optional. Linting optional/nulls with this patch is required for #1166 to land nicely. Previously, return types were not being linted in `api.md`. This is fixed, along with many broken return types. This patch considers `?` to mean nullable, and has some heuristics to determine optionality. I believe this to be the minimal patch needed to unblock #1166. After it lands, we can consider changing the api docs to hopefully remove some heuristics and strangeness.
461e4dc
to
f5c458c
Compare
Ready for another look! New gist: https://gist.github.com/JoelEinbinder/4d69cd5373d00443c1b5efa72ae114bd
Done
Done via #1206
Yes
English review of the api is up next. I'll fix it then.
I was using 'Options' everywhere. I changed it to the argument name. This works better everywhere except for Note that this means changing the argument names could be a breaking change, because the types will change.
Done via #1206
Done |
I don't like this restriction. Let's brainstorm and follow up. |
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.
Let's land it!
@@ -48,7 +48,7 @@ interface TestSetup<STATE> { | |||
MAC: boolean; | |||
LINUX: boolean; | |||
WIN: boolean; | |||
playwright: import('../src/server/browserType').BrowserType; | |||
playwright: import('../src/server/browserType').BrowserType<import('../src/browser').Browser>; |
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.
Let's migrate this whole file to public types in a follow up.
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.
Definitely!
const objectDefinitions = []; | ||
const handledMethods = new Set(); | ||
/** @type {Documentation} */ | ||
let documentation; |
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.
WDYT about slowly rewriting all our utils into typescript? Having types will definitely help.
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.
We have types through JSDoc. I'm always against typescript, so I am biased. With the utils, is harder because the utils will depend on the library to be built and the library depends on the utils to be built, so you end up needing to require the npm playwright as a devDependency of playwright or having separate bootstrap logic. I'd rather avoid it.
Filed as #1439 |
#6
A place for discussion