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

chore: migrate src/Connection to TypeScript #5694

Merged
merged 2 commits into from Apr 21, 2020
Merged

Conversation

jackfranklin
Copy link
Collaborator

This commit migrates src/Connection to TypeScript. It also changes its
exports to be ESM because TypeScript's support for exporting values to
use as types via CommonJS is poor (by design) and so rather than battle
that it made more sense to migrate the file to ESM.

The good news is that TypeScript is still outputting to lib/ as
CommonJS, so the fact that we author in ESM is actually not a breaking
change at all.

So going forwards we will:

  • migrate TS files to use ESM for importing and exporting
  • continue to output to lib/ as CommonJS
  • continue to use CommonJS requires when in a src/*.js file

I'd also like to split Connection.ts into two; I think the
CDPSession class belongs in its own file, but I will do that in
another PR to avoid this one becoming bigger than it already is.

I also turned off @typescript-eslint/no-use-before-define as I don't
think it was adding value and Puppeteer's codebase seems to have a style
of declaring helper functions at the bottom which is fine by me.

@mathiasbynens
Copy link
Member

Yay for modules!

Copy link
Member

@mathiasbynens mathiasbynens left a comment

Choose a reason for hiding this comment

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

Still LGTM

This commit migrates `src/Connection` to TypeScript. It also changes its
exports to be ESM because TypeScript's support for exporting values to
use as types via CommonJS is poor (by design) and so rather than battle
that it made more sense to migrate the file to ESM.

The good news is that TypeScript is still outputting to `lib/` as
CommonJS, so the fact that we author in ESM is actually not a breaking
change at all.

So going forwards we will:

* migrate TS files to use ESM for importing and exporting
* continue to output to `lib/` as CommonJS
* continue to use CommonJS requires when in a `src/*.js` file

I'd also like to split `Connection.ts` into two; I think the
`CDPSession` class belongs in its own file, but I will do that in
another PR to avoid this one becoming bigger than it already is.

I also turned off `@typescript-eslint/no-use-before-define` as I don't
think it was adding value and Puppeteer's codebase seems to have a style
of declaring helper functions at the bottom which is fine by me.

Finally, I updated the DocLint tool so it knows of expected method
mismatches. It was either that or come up with a smart way to support
TypeScript generics in DocLint and given we don't want to use DocLint
that much longer that didn't feel worth it.
const id = this._connection._rawSend({
sessionId: this._sessionId,
method,
params: params || {}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

hey @mjzffr I think there might be a Firefox bug here with the fact that it's expecting params to be present. Without this || {} some Firefox specs fail like so:

 1) Page.click
       should not hang with touch-enabled viewports:
     Error: Protocol error (Page.reload): (destructured parameter) is undefined reload@chrome://remote/content/domains/content/Page.jsm:135:1
execute@chrome://remote/content/domains/DomainCache.jsm:99:25
receiveMessage@chrome://remote/content/sessions/ContentProcessSession.jsm:69:45
MessageListener.receiveMessage*ContentProcessSession@chrome://remote/content/sessions/ContentProcessSession.jsm:27:25
@chrome://remote/content/sessions/frame-script.js:12:1
      at Promise (lib/Connection.js:147:63)
      at new Promise (<anonymous>)
      at CDPSession.send (lib/Connection.js:146:16)
      at Page.reload (lib/Page.js:630:26)
      at Page.<anonymous> (lib/helper.js:82:27)
      at Page.setViewport (lib/Page.js:776:24)
      at process._tickCallback (internal/process/next_tick.js:68:7)
    -- ASYNC --
      at Page.<anonymous> (lib/helper.js:81:19)
      at Context.it (test/click.spec.js:207:16)
      at process._tickCallback (internal/process/next_tick.js:68:7)

However Chrome is fine. I think that maybe FF is expecting params where it shouldn't? This is an easy workaround for now but might be worth looking into. I also might have misunderstood the issue so sorry if that's the case. Also pinging @mathiasbynens for any thoughts.

Copy link
Contributor

Choose a reason for hiding this comment

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

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

Successfully merging this pull request may close these issues.

None yet

4 participants