Commit Graph

23 Commits

Author SHA1 Message Date
Jack Franklin
46fc6ca41a
feat(types): improve typing of .evaluate() (#6096)
* feat(types): improve typing of `.evaluate()`

This is the start of the work to take the types from the
`@types/puppeteer` repository and port them into our repo so we can ship
our built-in types out the box.

This change types the `evaluate` function properly. It takes a generic
type which is the type of the function you're passing, and the arguments
and the return that you get back from the `evaluate` call are typed
correctly.
2020-06-25 13:38:01 +01:00
Jack Franklin
70a900e93b
chore: fix ESLint violation and lessen rule strictness (#6081) 2020-06-23 12:55:42 +01:00
Jack Franklin
e7b91a7f41
chore: enforce a max line length on comments (#6055) 2020-06-19 15:39:03 +01:00
Jack Franklin
4fdb1e3cab
chore: add Prettier (#5825) 2020-05-07 12:54:55 +02:00
Jack Franklin
d69fbb9974
chore: Enforce array type styles in TypeScript (#5765)
This change enforces how we type arrays, e.g. choosing between:

* `string[]`
* `Array<string>`

I've gone for the `array-simple` option [1] which enforces that:

* primitive types and type references use `X[]`
* complex types use `Array<X>`

For example, we'd type an array of strings as `string[]`, but an array
of a union type as `Array<SomeUnionType>`.

[1]: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/array-type.md
2020-04-28 15:06:43 +01:00
Jack Franklin
1ccfbcb684
chore: enforce naming of errors in catch blocks (#5763) 2020-04-28 15:16:28 +02:00
Jack Franklin
29ebd0bb3e
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript

I spent a while trying to decide on the best course of action for
typing the `evaluate` function.

Ideally I wanted to use generics so that as a user you could type
something like:

```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```

And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:

* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.

So in the end I went with one generic which is the return type of the
function:

```
handle.evaluate<boolean>((node, x) => true, 5)
```

And `node` and `x` get typed as `any` which means you can tell TS
yourself:

```
handle.evaluate<boolean>((node: HTMLElement, x:  number) => true, 5)
```

I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.

I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 10:33:44 +01:00
Jack Franklin
e3922ea1f3
chore: enforce consistent spacing around object curlys (#5700)
The codebase was incredibly inconsistent with the use of spacing around
curly braces, e.g.:

```
// this?
const a = {b: 1}
// or?
const a = { b: 1 }
```

This extended into import statements also. Google's styleguide is no
spacing, so we're going with that.
2020-04-21 10:40:04 +01:00
Jack Franklin
a614bc45aa
chore: migrate src/Connection to TypeScript (#5694)
* chore: migrate `src/Connection` to TypeScript

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.

* Fix params being required
2020-04-21 09:20:25 +01:00
Jack Franklin
1a57ba22a8
chore: Migrate TaskQueue to TypeScript (#5658)
This is a simple module but took a bit of work because:

* It wraps a Promise that can return basically anything. In a pure TS
codebase we'd solve these with generics, so you could do `new
TaskQueue<T>` where `T` will be what's returned from the queue, but
because we're calling that from JS we can't yet. I've left a TODO and
once we migrate the call sites to TS we can do a much better job than
the `void | any` type I've gone with for now.

* It was used in typedefs via `Puppeteer.TaskQueue`. I've removed that
entry from `externs.d.ts` in favour of importing it and using the type
directly. This does mean that we have imports that ESLint doesn't
realiase are actually used but I think this is better than maintaining
`externs.d.ts`.
2020-04-17 11:32:56 +02:00
Jack Franklin
3e4c8c9d0d
chore(typescript): migrate src/Dialog (#5639)
This PR changes `src/Dialog.js` to `src/Dialog.ts` and rewrites
accordingly. Most of the changes are straight forward; the only
interesting one from a TS point of view is the `DialogType` enum. I
expose it again as `Dialog.Type` to avoid a breaking change.

This PR also exposed some bugs with our ESLint TypeScript settings and
applying the overrides, so I fixed those too.

I also updated our DocLint tool to work on TS source files over JS lib
files if they exist. This is the minimal change to keep the existing doc
system working as we're working on moving away from this system longer
term.
2020-04-16 14:59:28 +01:00
Jack Franklin
2529ee6508
chore(eslint): add eslint typescript linting (#5635)
This commit adds linting for `*.ts` files and loads up the recommended
list of TS rules from the ESLint TypeScript plugin. We can adjust the
exact rules overtime, but starting with the recommended list seems
sensible.
2020-04-14 12:08:52 +01:00
Jack Franklin
17cd8703f9
chore: migrate unit tests to Mocha (#5600)
Rather than maintain our own test runner we should instead lean on the community and use Mocha which is very popular and also our test runner of choice in DevTools too.

Note that this commit doesn't remove the TestRunner source as it's still used for other unit tests, but they will be updated in a future PR and then we can remove the TestRunner.

The main bulk of this PR is updating the tests as the old TestRunner passed in contextual data via the `it` function callback whereas Mocha does not, so we introduce some helpers for the tests to make it easier.
2020-04-09 07:56:25 +02:00
Andrey Lushnikov
3511a35fa4
test: fix fixtures test when run with env DUMPIO=1 (#4123)
The DUMPIO env variable is propagated to a spawned process
and results in unfortunate stdout.
2019-03-13 16:26:28 -07:00
Andrey Lushnikov
e6725e15af
tests: drop jasmine test runner (#1519)
This patch introduces a tiny test runner to run puppeteer tests.
The test runner is self-container and allows parallel (wrt IO) test execution.
It will also allow us to split tests into multiple files if necessary.

Comparing to the jasmine, the testrunner supports parallel execution, properly
handles "unhandled promise rejection" event and signals.

Comparing to ava/jest, the testrunner doesn't run multiple node processes,
which makes it simpler but sufficient for our goals.
2017-12-07 16:37:22 -08:00
JoelEinbinder
a756bc868f Don't complain about Windows line endings on Windows (#496) 2017-08-23 11:56:59 -07:00
JoelEinbinder
a526e9f9fb Stricter eslint rules (#472)
Accept stricter eslint rules.
2017-08-22 14:18:07 -07:00
Eric Bidelman
1f9b4fb4c8 Change let into const (#457)
This patch:
- changes `let` into `const` throughout codebase
- adds eslint check to prefer const over let
2017-08-21 16:39:04 -07:00
Andrey Lushnikov
819fa355f4 Convert var's to let's
This patch:
- converts all var's to let's throughout the codebase
- enforces the let's over var's via the eslint rule
2017-06-22 14:58:39 -07:00
Pavel Feldman
437a93b26e Reformat code using 2 spaces 2017-06-21 14:11:52 -07:00
Pavel Feldman
84bc09bce1 Revert "Reformat codebase into 2-spaces"
This reverts commit d0d1ee303e.
2017-06-21 14:11:52 -07:00
Andrey Lushnikov
448ac4ce64 Reformat codebase into 2-spaces
This patch:
- reformats codebase to use 2-spaces instead of 4. This will
  align the project with other codebases (e.g. DevTools and Lighthouse)
- enables eslint indentation checking

References #19
2017-06-21 14:11:52 -07:00
Andrey Lushnikov
1f51384918 Introduce Eslint to validate style
This patch introduces eslint and fixes multiple minor code
style issues.
2017-06-11 01:32:59 -07:00