2018-02-09 03:59:46 +00:00
|
|
|
# Puppeteer
|
2018-01-11 08:28:36 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
[](https://github.com/puppeteer/puppeteer/actions?query=workflow%3ACI)
|
|
|
|
|
[](https://npmjs.org/package/puppeteer)
|
fix: much better TypeScript definitions (#6837)
This PR aims to vastly improve our TS types and how we ship them.
Our previous attempt at shipping TypeScript was unfortunately flawed for
many reasons when compared to the @types/puppeteer package:
* It only worked if you needed the default export. If you wanted to
import a type that Puppeteer uses, you'd have to do `import type X
from 'puppeteer/lib/...'`. This is not something we want to encourage
because that means our internal file structure becomes almost public
API.
* It gave absolutely no help to CommonJS users in JS files because it
would warn people they needed to do `const pptr =
require('puppeteer').default, which is not correct.
* I found a bug in the `evaluate` types which mean't you couldn't
override the types to provide more info, and TS would insist the types
were all `unknown`.
The goal of this PR is to support:
1. In a `ts` file, `import puppeteer from 'puppeteer'`
1. In a `ts` file, `import type {ElementHandle} from 'puppeteer'`
1. In a `ts` file, referencing a type as `puppeteer.ElementHandle`
1. In a `ts` file, you can get good type inference when running
`foo.evaluate(x => x.clientHeight)`.
1. In a `js` file using CJS, you can do `const puppeteer =
require('puppeteer')` and get good type help from VSCode.
To test this I created a new empty repository with two test files in,
one `.ts` file with this in:
https://gist.github.com/jackfranklin/22ba2f390f97c7312cd70025a2096fc8,
and a `js` file with this in:
https://gist.github.com/jackfranklin/06bed136fdb22419cb7a8a9a4d4ef32f.
These files included enough code to check that the types were behaving
as I expected.
The fix for our types was to make use of API Extractor, which we already
use for our docs, to "rollup" all the disparate type files that TS
generates into one large `types.d.ts` which contains all the various
types that we define, such as:
```ts
export declare class ElementHandle {...}
export type EvaluateFn ...
```
If we then update our `package.json` `types` field to point to that file
in `lib/types.d.ts`, this then allows a developer to write:
```
import type {ElementHandle} from 'puppeteer'
```
And get the correct type definitions. However, what the `types.d.ts`
file doesn't do out of the box is declare the default export, so
importing Puppeteer's default export to call a method such as `launch`
on it will get you an error.
That's where the `script/add-default-export-to-types.ts` comes in. It
appends the following to the auto-generated `types.d.ts` file:
```ts
declare const puppeteer: PuppeteerNode;
export = puppeteer;
```
This tells TypeScript what the default export is, and by using the
`export =` syntax, we make sure TS understands both in a TS ESM
environment and in a JS CJS environment.
Now the `build` step, which is run by GitHub Actions when we release,
will generate the `.d.ts` file and then extend it with the default
export code.
To ensure that I was generating a valid package, I created a new
repository locally with the two code samples linked in Gists above. I
then ran:
```
npm init -y
npm install --save-dev typescript
npx tsc --init
```
Which gives me a base to test from. In Puppeteer, I ran `npm pack`,
which packs the module into a tar that's almost identical to what would
be published, so I can be confident that the .d.ts files in there are
what would be published.
I then installed it:
```
npm install --save-dev ../../puppeteer/puppeteer-7.0.1-post.tgz
```
And then reloaded VSCode in my dummy project. By deliberately making
typos and hovering over the code, I could confirm that all the goals
listed above were met, and this seems like a vast improvement on our
types.
2021-02-09 08:00:42 +00:00
|
|
|
|
2022-07-01 11:52:39 +00:00
|
|
|
<img src="https://user-images.githubusercontent.com/10379601/29446482-04f7036a-841f-11e7-9872-91d1fc2ea683.png" height="200" align="right"/>
|
2017-08-15 17:08:32 +00:00
|
|
|
|
2022-10-28 06:49:28 +00:00
|
|
|
#### [Guides](https://pptr.dev/category/guides) | [API](https://pptr.dev/api) | [FAQ](https://pptr.dev/faq) | [Contributing](https://pptr.dev/contributing) | [Troubleshooting](https://pptr.dev/troubleshooting)
|
2017-06-19 23:37:55 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
> Puppeteer is a Node.js library which provides a high-level API to control
|
|
|
|
|
> Chrome/Chromium over the
|
|
|
|
|
> [DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/).
|
|
|
|
|
> Puppeteer runs in
|
|
|
|
|
> [headless](https://developers.google.com/web/updates/2017/04/headless-chrome)
|
|
|
|
|
> mode by default, but can be configured to run in full (non-headless)
|
|
|
|
|
> Chrome/Chromium.
|
2017-07-28 02:21:24 +00:00
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
#### What can I do?
|
2017-08-11 01:31:54 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
Most things that you can do manually in the browser can be done using Puppeteer!
|
|
|
|
|
Here are a few examples to get you started:
|
2017-08-11 01:31:54 +00:00
|
|
|
|
fix: much better TypeScript definitions (#6837)
This PR aims to vastly improve our TS types and how we ship them.
Our previous attempt at shipping TypeScript was unfortunately flawed for
many reasons when compared to the @types/puppeteer package:
* It only worked if you needed the default export. If you wanted to
import a type that Puppeteer uses, you'd have to do `import type X
from 'puppeteer/lib/...'`. This is not something we want to encourage
because that means our internal file structure becomes almost public
API.
* It gave absolutely no help to CommonJS users in JS files because it
would warn people they needed to do `const pptr =
require('puppeteer').default, which is not correct.
* I found a bug in the `evaluate` types which mean't you couldn't
override the types to provide more info, and TS would insist the types
were all `unknown`.
The goal of this PR is to support:
1. In a `ts` file, `import puppeteer from 'puppeteer'`
1. In a `ts` file, `import type {ElementHandle} from 'puppeteer'`
1. In a `ts` file, referencing a type as `puppeteer.ElementHandle`
1. In a `ts` file, you can get good type inference when running
`foo.evaluate(x => x.clientHeight)`.
1. In a `js` file using CJS, you can do `const puppeteer =
require('puppeteer')` and get good type help from VSCode.
To test this I created a new empty repository with two test files in,
one `.ts` file with this in:
https://gist.github.com/jackfranklin/22ba2f390f97c7312cd70025a2096fc8,
and a `js` file with this in:
https://gist.github.com/jackfranklin/06bed136fdb22419cb7a8a9a4d4ef32f.
These files included enough code to check that the types were behaving
as I expected.
The fix for our types was to make use of API Extractor, which we already
use for our docs, to "rollup" all the disparate type files that TS
generates into one large `types.d.ts` which contains all the various
types that we define, such as:
```ts
export declare class ElementHandle {...}
export type EvaluateFn ...
```
If we then update our `package.json` `types` field to point to that file
in `lib/types.d.ts`, this then allows a developer to write:
```
import type {ElementHandle} from 'puppeteer'
```
And get the correct type definitions. However, what the `types.d.ts`
file doesn't do out of the box is declare the default export, so
importing Puppeteer's default export to call a method such as `launch`
on it will get you an error.
That's where the `script/add-default-export-to-types.ts` comes in. It
appends the following to the auto-generated `types.d.ts` file:
```ts
declare const puppeteer: PuppeteerNode;
export = puppeteer;
```
This tells TypeScript what the default export is, and by using the
`export =` syntax, we make sure TS understands both in a TS ESM
environment and in a JS CJS environment.
Now the `build` step, which is run by GitHub Actions when we release,
will generate the `.d.ts` file and then extend it with the default
export code.
To ensure that I was generating a valid package, I created a new
repository locally with the two code samples linked in Gists above. I
then ran:
```
npm init -y
npm install --save-dev typescript
npx tsc --init
```
Which gives me a base to test from. In Puppeteer, I ran `npm pack`,
which packs the module into a tar that's almost identical to what would
be published, so I can be confident that the .d.ts files in there are
what would be published.
I then installed it:
```
npm install --save-dev ../../puppeteer/puppeteer-7.0.1-post.tgz
```
And then reloaded VSCode in my dummy project. By deliberately making
typos and hovering over the code, I could confirm that all the goals
listed above were met, and this seems like a vast improvement on our
types.
2021-02-09 08:00:42 +00:00
|
|
|
- Generate screenshots and PDFs of pages.
|
2022-10-17 11:07:41 +00:00
|
|
|
- Crawl a SPA (Single-Page Application) and generate pre-rendered content (i.e.
|
|
|
|
|
"SSR" (Server-Side Rendering)).
|
fix: much better TypeScript definitions (#6837)
This PR aims to vastly improve our TS types and how we ship them.
Our previous attempt at shipping TypeScript was unfortunately flawed for
many reasons when compared to the @types/puppeteer package:
* It only worked if you needed the default export. If you wanted to
import a type that Puppeteer uses, you'd have to do `import type X
from 'puppeteer/lib/...'`. This is not something we want to encourage
because that means our internal file structure becomes almost public
API.
* It gave absolutely no help to CommonJS users in JS files because it
would warn people they needed to do `const pptr =
require('puppeteer').default, which is not correct.
* I found a bug in the `evaluate` types which mean't you couldn't
override the types to provide more info, and TS would insist the types
were all `unknown`.
The goal of this PR is to support:
1. In a `ts` file, `import puppeteer from 'puppeteer'`
1. In a `ts` file, `import type {ElementHandle} from 'puppeteer'`
1. In a `ts` file, referencing a type as `puppeteer.ElementHandle`
1. In a `ts` file, you can get good type inference when running
`foo.evaluate(x => x.clientHeight)`.
1. In a `js` file using CJS, you can do `const puppeteer =
require('puppeteer')` and get good type help from VSCode.
To test this I created a new empty repository with two test files in,
one `.ts` file with this in:
https://gist.github.com/jackfranklin/22ba2f390f97c7312cd70025a2096fc8,
and a `js` file with this in:
https://gist.github.com/jackfranklin/06bed136fdb22419cb7a8a9a4d4ef32f.
These files included enough code to check that the types were behaving
as I expected.
The fix for our types was to make use of API Extractor, which we already
use for our docs, to "rollup" all the disparate type files that TS
generates into one large `types.d.ts` which contains all the various
types that we define, such as:
```ts
export declare class ElementHandle {...}
export type EvaluateFn ...
```
If we then update our `package.json` `types` field to point to that file
in `lib/types.d.ts`, this then allows a developer to write:
```
import type {ElementHandle} from 'puppeteer'
```
And get the correct type definitions. However, what the `types.d.ts`
file doesn't do out of the box is declare the default export, so
importing Puppeteer's default export to call a method such as `launch`
on it will get you an error.
That's where the `script/add-default-export-to-types.ts` comes in. It
appends the following to the auto-generated `types.d.ts` file:
```ts
declare const puppeteer: PuppeteerNode;
export = puppeteer;
```
This tells TypeScript what the default export is, and by using the
`export =` syntax, we make sure TS understands both in a TS ESM
environment and in a JS CJS environment.
Now the `build` step, which is run by GitHub Actions when we release,
will generate the `.d.ts` file and then extend it with the default
export code.
To ensure that I was generating a valid package, I created a new
repository locally with the two code samples linked in Gists above. I
then ran:
```
npm init -y
npm install --save-dev typescript
npx tsc --init
```
Which gives me a base to test from. In Puppeteer, I ran `npm pack`,
which packs the module into a tar that's almost identical to what would
be published, so I can be confident that the .d.ts files in there are
what would be published.
I then installed it:
```
npm install --save-dev ../../puppeteer/puppeteer-7.0.1-post.tgz
```
And then reloaded VSCode in my dummy project. By deliberately making
typos and hovering over the code, I could confirm that all the goals
listed above were met, and this seems like a vast improvement on our
types.
2021-02-09 08:00:42 +00:00
|
|
|
- Automate form submission, UI testing, keyboard input, etc.
|
2022-10-17 11:07:41 +00:00
|
|
|
- Create an automated testing environment using the latest JavaScript and
|
|
|
|
|
browser features.
|
|
|
|
|
- Capture a
|
|
|
|
|
[timeline trace](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference)
|
|
|
|
|
of your site to help diagnose performance issues.
|
fix: much better TypeScript definitions (#6837)
This PR aims to vastly improve our TS types and how we ship them.
Our previous attempt at shipping TypeScript was unfortunately flawed for
many reasons when compared to the @types/puppeteer package:
* It only worked if you needed the default export. If you wanted to
import a type that Puppeteer uses, you'd have to do `import type X
from 'puppeteer/lib/...'`. This is not something we want to encourage
because that means our internal file structure becomes almost public
API.
* It gave absolutely no help to CommonJS users in JS files because it
would warn people they needed to do `const pptr =
require('puppeteer').default, which is not correct.
* I found a bug in the `evaluate` types which mean't you couldn't
override the types to provide more info, and TS would insist the types
were all `unknown`.
The goal of this PR is to support:
1. In a `ts` file, `import puppeteer from 'puppeteer'`
1. In a `ts` file, `import type {ElementHandle} from 'puppeteer'`
1. In a `ts` file, referencing a type as `puppeteer.ElementHandle`
1. In a `ts` file, you can get good type inference when running
`foo.evaluate(x => x.clientHeight)`.
1. In a `js` file using CJS, you can do `const puppeteer =
require('puppeteer')` and get good type help from VSCode.
To test this I created a new empty repository with two test files in,
one `.ts` file with this in:
https://gist.github.com/jackfranklin/22ba2f390f97c7312cd70025a2096fc8,
and a `js` file with this in:
https://gist.github.com/jackfranklin/06bed136fdb22419cb7a8a9a4d4ef32f.
These files included enough code to check that the types were behaving
as I expected.
The fix for our types was to make use of API Extractor, which we already
use for our docs, to "rollup" all the disparate type files that TS
generates into one large `types.d.ts` which contains all the various
types that we define, such as:
```ts
export declare class ElementHandle {...}
export type EvaluateFn ...
```
If we then update our `package.json` `types` field to point to that file
in `lib/types.d.ts`, this then allows a developer to write:
```
import type {ElementHandle} from 'puppeteer'
```
And get the correct type definitions. However, what the `types.d.ts`
file doesn't do out of the box is declare the default export, so
importing Puppeteer's default export to call a method such as `launch`
on it will get you an error.
That's where the `script/add-default-export-to-types.ts` comes in. It
appends the following to the auto-generated `types.d.ts` file:
```ts
declare const puppeteer: PuppeteerNode;
export = puppeteer;
```
This tells TypeScript what the default export is, and by using the
`export =` syntax, we make sure TS understands both in a TS ESM
environment and in a JS CJS environment.
Now the `build` step, which is run by GitHub Actions when we release,
will generate the `.d.ts` file and then extend it with the default
export code.
To ensure that I was generating a valid package, I created a new
repository locally with the two code samples linked in Gists above. I
then ran:
```
npm init -y
npm install --save-dev typescript
npx tsc --init
```
Which gives me a base to test from. In Puppeteer, I ran `npm pack`,
which packs the module into a tar that's almost identical to what would
be published, so I can be confident that the .d.ts files in there are
what would be published.
I then installed it:
```
npm install --save-dev ../../puppeteer/puppeteer-7.0.1-post.tgz
```
And then reloaded VSCode in my dummy project. By deliberately making
typos and hovering over the code, I could confirm that all the goals
listed above were met, and this seems like a vast improvement on our
types.
2021-02-09 08:00:42 +00:00
|
|
|
- Test Chrome Extensions.
|
|
|
|
|
|
2017-08-11 01:31:54 +00:00
|
|
|
## Getting Started
|
2017-07-31 22:15:43 +00:00
|
|
|
|
2017-08-11 01:31:54 +00:00
|
|
|
### Installation
|
2017-05-11 07:06:41 +00:00
|
|
|
|
2017-08-11 01:31:54 +00:00
|
|
|
To use Puppeteer in your project, run:
|
2018-02-09 03:59:46 +00:00
|
|
|
|
|
|
|
|
```bash
|
2018-04-03 17:26:21 +00:00
|
|
|
npm i puppeteer
|
2022-10-13 08:46:53 +00:00
|
|
|
# or `yarn add puppeteer`
|
|
|
|
|
# or `pnpm i puppeteer`
|
2017-06-20 02:17:11 +00:00
|
|
|
```
|
|
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
When you install Puppeteer, it automatically downloads a recent version of
|
|
|
|
|
Chromium (~170MB macOS, ~282MB Linux, ~280MB Windows) that is
|
|
|
|
|
[guaranteed to work](https://pptr.dev/faq#q-why-doesnt-puppeteer-vxxx-work-with-chromium-vyyy)
|
|
|
|
|
with Puppeteer. For a version of Puppeteer without installation, see
|
|
|
|
|
[`puppeteer-core`](#puppeteer-core).
|
2017-06-19 23:37:55 +00:00
|
|
|
|
2022-10-28 06:49:28 +00:00
|
|
|
#### Configuration
|
2022-10-24 07:07:05 +00:00
|
|
|
|
|
|
|
|
Puppeteer uses several defaults that can be customized through configuration
|
|
|
|
|
files.
|
|
|
|
|
|
|
|
|
|
For example, to change the default cache directory Puppeteer uses to install
|
|
|
|
|
browsers, you can add a `.puppeteerrc.cjs` (or `puppeteer.config.cjs`) at the
|
|
|
|
|
root of your application with the contents
|
|
|
|
|
|
|
|
|
|
```js
|
|
|
|
|
const {join} = require('path');
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @type {import("puppeteer").Configuration}
|
|
|
|
|
*/
|
|
|
|
|
module.exports = {
|
|
|
|
|
// Changes the cache location for Puppeteer.
|
|
|
|
|
cacheDirectory: join(__dirname, '.cache', 'puppeteer'),
|
|
|
|
|
};
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
After adding the configuration file, you will need to remove and reinstall
|
|
|
|
|
`puppeteer` for it to take effect.
|
|
|
|
|
|
2022-10-28 06:49:28 +00:00
|
|
|
See the [configuration guide](https://pptr.dev/guides/configuration) for more
|
|
|
|
|
information.
|
2022-07-01 11:52:39 +00:00
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
#### `puppeteer-core`
|
2022-07-01 11:52:39 +00:00
|
|
|
|
|
|
|
|
Every release since v1.7.0 we publish two packages:
|
|
|
|
|
|
|
|
|
|
- [`puppeteer`](https://www.npmjs.com/package/puppeteer)
|
|
|
|
|
- [`puppeteer-core`](https://www.npmjs.com/package/puppeteer-core)
|
|
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
`puppeteer` is a _product_ for browser automation. When installed, it downloads
|
|
|
|
|
a version of Chromium, which it then drives using `puppeteer-core`. Being an
|
2022-10-28 06:49:28 +00:00
|
|
|
end-user product, `puppeteer` automates several workflows using reasonable
|
|
|
|
|
defaults [that can be customized](https://pptr.dev/guides/configuration).
|
2022-07-01 11:52:39 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
`puppeteer-core` is a _library_ to help drive anything that supports DevTools
|
2022-10-24 07:07:05 +00:00
|
|
|
protocol. Being a library, `puppeteer-core` is fully driven through its
|
|
|
|
|
programmatic interface implying no defaults are assumed and `puppeteer-core`
|
|
|
|
|
will not download Chromium when installed.
|
|
|
|
|
|
2022-10-28 06:49:28 +00:00
|
|
|
You should use `puppeteer-core` if you are
|
|
|
|
|
[connecting to a remote browser](https://pptr.dev/api/puppeteer.puppeteer.connect)
|
|
|
|
|
or [managing browsers yourself](https://pptr.dev/api/puppeteer.browserfetcher).
|
|
|
|
|
If you are managing browsers yourself, you will need to call
|
2022-10-17 11:07:41 +00:00
|
|
|
[`puppeteer.launch`](https://pptr.dev/api/puppeteer.puppeteernode.launch) with
|
2022-10-24 07:07:05 +00:00
|
|
|
an an explicit
|
2022-10-17 11:07:41 +00:00
|
|
|
[`executablePath`](https://pptr.dev/api/puppeteer.launchoptions.executablepath)
|
2022-10-28 06:49:28 +00:00
|
|
|
(or [`channel`](https://pptr.dev/api/puppeteer.launchoptions.channel) if it's
|
|
|
|
|
installed in a standard location).
|
2022-07-01 11:52:39 +00:00
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
When using `puppeteer-core`, remember to change the import:
|
2022-07-01 11:52:39 +00:00
|
|
|
|
|
|
|
|
```ts
|
2022-10-13 08:46:53 +00:00
|
|
|
import puppeteer from 'puppeteer-core';
|
2022-07-01 11:52:39 +00:00
|
|
|
```
|
|
|
|
|
|
2017-08-11 01:31:54 +00:00
|
|
|
### Usage
|
2017-06-19 23:37:55 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
Puppeteer follows the latest
|
|
|
|
|
[maintenance LTS](https://github.com/nodejs/Release#release-schedule) version of
|
|
|
|
|
Node.
|
2019-10-16 15:00:20 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
Puppeteer will be familiar to people using other browser testing frameworks. You
|
|
|
|
|
[launch](https://pptr.dev/api/puppeteer.puppeteernode.launch)/[connect](https://pptr.dev/api/puppeteer.puppeteernode.connect)
|
|
|
|
|
a [browser](https://pptr.dev/api/puppeteer.browser),
|
|
|
|
|
[create](https://pptr.dev/api/puppeteer.browser.newpage) some
|
|
|
|
|
[pages](https://pptr.dev/api/puppeteer.page), and then manipulate them with
|
|
|
|
|
[Puppeteer's API](https://pptr.dev/api).
|
2018-03-07 05:50:06 +00:00
|
|
|
|
2022-10-28 06:49:28 +00:00
|
|
|
For more in-depth usage, check our [guides](https://pptr.dev/category/guides)
|
|
|
|
|
and [examples](https://github.com/puppeteer/puppeteer/tree/main/examples).
|
2017-08-11 01:31:54 +00:00
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
#### Example
|
2017-08-24 16:13:49 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
The following example searches
|
|
|
|
|
[developers.google.com/web](https://developers.google.com/web) for articles
|
|
|
|
|
tagged "Headless Chrome" and scrape results from the results page.
|
2018-03-07 05:50:06 +00:00
|
|
|
|
2022-07-01 11:52:39 +00:00
|
|
|
```ts
|
2022-10-13 08:46:53 +00:00
|
|
|
import puppeteer from 'puppeteer';
|
2017-08-24 16:13:49 +00:00
|
|
|
|
|
|
|
|
(async () => {
|
|
|
|
|
const browser = await puppeteer.launch();
|
|
|
|
|
const page = await browser.newPage();
|
|
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
await page.goto('https://developers.google.com/web/');
|
2017-08-24 16:13:49 +00:00
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
// Type into search box.
|
|
|
|
|
await page.type('.devsite-search-field', 'Headless Chrome');
|
2018-03-07 05:50:06 +00:00
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
// Wait for suggest overlay to appear and click "show all results".
|
|
|
|
|
const allResultsSelector = '.devsite-suggest-all-results';
|
|
|
|
|
await page.waitForSelector(allResultsSelector);
|
|
|
|
|
await page.click(allResultsSelector);
|
2022-08-05 09:00:09 +00:00
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
// Wait for the results page to load and display the results.
|
|
|
|
|
const resultsSelector = '.gsc-results .gs-title';
|
|
|
|
|
await page.waitForSelector(resultsSelector);
|
2022-08-05 09:00:09 +00:00
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
// Extract the results from the page.
|
|
|
|
|
const links = await page.evaluate(resultsSelector => {
|
|
|
|
|
return [...document.querySelectorAll(resultsSelector)].map(anchor => {
|
|
|
|
|
const title = anchor.textContent.split('|')[0].trim();
|
|
|
|
|
return `${title} - ${anchor.href}`;
|
|
|
|
|
});
|
|
|
|
|
}, resultsSelector);
|
2022-07-01 11:52:39 +00:00
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
// Print all the files.
|
|
|
|
|
console.log(links.join('\n'));
|
2022-07-01 11:52:39 +00:00
|
|
|
|
|
|
|
|
await browser.close();
|
|
|
|
|
})();
|
|
|
|
|
```
|
|
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
### Default runtime settings
|
2017-08-11 01:31:54 +00:00
|
|
|
|
2017-08-15 00:55:40 +00:00
|
|
|
**1. Uses Headless mode**
|
2017-08-11 01:31:54 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
Puppeteer launches Chromium in
|
|
|
|
|
[headless mode](https://developers.google.com/web/updates/2017/04/headless-chrome).
|
|
|
|
|
To launch a full version of Chromium, set the
|
|
|
|
|
[`headless`](https://pptr.dev/api/puppeteer.browserlaunchargumentoptions.headless)
|
|
|
|
|
option when launching a browser:
|
2017-08-11 01:31:54 +00:00
|
|
|
|
2022-07-01 11:52:39 +00:00
|
|
|
```ts
|
2022-06-22 13:25:44 +00:00
|
|
|
const browser = await puppeteer.launch({headless: false}); // default is true
|
2017-08-11 01:31:54 +00:00
|
|
|
```
|
|
|
|
|
|
2017-08-15 00:55:40 +00:00
|
|
|
**2. Runs a bundled version of Chromium**
|
2017-06-20 02:17:11 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
By default, Puppeteer downloads and uses a specific version of Chromium so its
|
|
|
|
|
API is guaranteed to work out of the box. To use Puppeteer with a different
|
|
|
|
|
version of Chrome or Chromium, pass in the executable's path when creating a
|
|
|
|
|
`Browser` instance:
|
2017-08-11 01:31:54 +00:00
|
|
|
|
2022-07-01 11:52:39 +00:00
|
|
|
```ts
|
2022-06-22 13:25:44 +00:00
|
|
|
const browser = await puppeteer.launch({executablePath: '/path/to/Chrome'});
|
2017-08-15 00:55:40 +00:00
|
|
|
```
|
|
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
You can also use Puppeteer with Firefox Nightly (experimental support). See
|
|
|
|
|
[`Puppeteer.launch`](https://pptr.dev/api/puppeteer.puppeteernode.launch) for
|
|
|
|
|
more information.
|
2017-08-15 00:55:40 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
See
|
|
|
|
|
[`this article`](https://www.howtogeek.com/202825/what%E2%80%99s-the-difference-between-chromium-and-chrome/)
|
|
|
|
|
for a description of the differences between Chromium and Chrome.
|
|
|
|
|
[`This article`](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/chromium_browser_vs_google_chrome.md)
|
|
|
|
|
describes some differences for Linux users.
|
2017-12-15 03:09:48 +00:00
|
|
|
|
2017-08-15 00:55:40 +00:00
|
|
|
**3. Creates a fresh user profile**
|
2017-08-11 01:31:54 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
Puppeteer creates its own browser user profile which it **cleans up on every
|
|
|
|
|
run**.
|
2017-06-20 02:17:11 +00:00
|
|
|
|
2022-10-13 08:46:53 +00:00
|
|
|
#### Using Docker
|
|
|
|
|
|
2022-10-28 06:49:28 +00:00
|
|
|
See our [Docker guide](https://pptr.dev/guides/docker).
|
2022-10-13 08:46:53 +00:00
|
|
|
|
|
|
|
|
#### Using Chrome Extensions
|
|
|
|
|
|
2022-10-28 06:49:28 +00:00
|
|
|
See our [Chrome extensions guide](https://pptr.dev/guides/chrome-extensions).
|
2018-01-11 08:28:36 +00:00
|
|
|
|
2018-08-10 08:34:45 +00:00
|
|
|
## Resources
|
2017-06-20 02:17:11 +00:00
|
|
|
|
2022-07-01 11:52:39 +00:00
|
|
|
- [API Documentation](https://pptr.dev/api)
|
2022-10-28 06:49:28 +00:00
|
|
|
- [Guides](https://pptr.dev/category/guides)
|
2022-07-01 11:52:39 +00:00
|
|
|
- [Examples](https://github.com/puppeteer/puppeteer/tree/main/examples)
|
2018-08-10 08:34:45 +00:00
|
|
|
- [Community list of Puppeteer resources](https://github.com/transitive-bullshit/awesome-puppeteer)
|
2017-05-11 07:06:41 +00:00
|
|
|
|
2022-07-01 11:52:39 +00:00
|
|
|
## Contributing
|
fix: much better TypeScript definitions (#6837)
This PR aims to vastly improve our TS types and how we ship them.
Our previous attempt at shipping TypeScript was unfortunately flawed for
many reasons when compared to the @types/puppeteer package:
* It only worked if you needed the default export. If you wanted to
import a type that Puppeteer uses, you'd have to do `import type X
from 'puppeteer/lib/...'`. This is not something we want to encourage
because that means our internal file structure becomes almost public
API.
* It gave absolutely no help to CommonJS users in JS files because it
would warn people they needed to do `const pptr =
require('puppeteer').default, which is not correct.
* I found a bug in the `evaluate` types which mean't you couldn't
override the types to provide more info, and TS would insist the types
were all `unknown`.
The goal of this PR is to support:
1. In a `ts` file, `import puppeteer from 'puppeteer'`
1. In a `ts` file, `import type {ElementHandle} from 'puppeteer'`
1. In a `ts` file, referencing a type as `puppeteer.ElementHandle`
1. In a `ts` file, you can get good type inference when running
`foo.evaluate(x => x.clientHeight)`.
1. In a `js` file using CJS, you can do `const puppeteer =
require('puppeteer')` and get good type help from VSCode.
To test this I created a new empty repository with two test files in,
one `.ts` file with this in:
https://gist.github.com/jackfranklin/22ba2f390f97c7312cd70025a2096fc8,
and a `js` file with this in:
https://gist.github.com/jackfranklin/06bed136fdb22419cb7a8a9a4d4ef32f.
These files included enough code to check that the types were behaving
as I expected.
The fix for our types was to make use of API Extractor, which we already
use for our docs, to "rollup" all the disparate type files that TS
generates into one large `types.d.ts` which contains all the various
types that we define, such as:
```ts
export declare class ElementHandle {...}
export type EvaluateFn ...
```
If we then update our `package.json` `types` field to point to that file
in `lib/types.d.ts`, this then allows a developer to write:
```
import type {ElementHandle} from 'puppeteer'
```
And get the correct type definitions. However, what the `types.d.ts`
file doesn't do out of the box is declare the default export, so
importing Puppeteer's default export to call a method such as `launch`
on it will get you an error.
That's where the `script/add-default-export-to-types.ts` comes in. It
appends the following to the auto-generated `types.d.ts` file:
```ts
declare const puppeteer: PuppeteerNode;
export = puppeteer;
```
This tells TypeScript what the default export is, and by using the
`export =` syntax, we make sure TS understands both in a TS ESM
environment and in a JS CJS environment.
Now the `build` step, which is run by GitHub Actions when we release,
will generate the `.d.ts` file and then extend it with the default
export code.
To ensure that I was generating a valid package, I created a new
repository locally with the two code samples linked in Gists above. I
then ran:
```
npm init -y
npm install --save-dev typescript
npx tsc --init
```
Which gives me a base to test from. In Puppeteer, I ran `npm pack`,
which packs the module into a tar that's almost identical to what would
be published, so I can be confident that the .d.ts files in there are
what would be published.
I then installed it:
```
npm install --save-dev ../../puppeteer/puppeteer-7.0.1-post.tgz
```
And then reloaded VSCode in my dummy project. By deliberately making
typos and hovering over the code, I could confirm that all the goals
listed above were met, and this seems like a vast improvement on our
types.
2021-02-09 08:00:42 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
Check out our [contributing guide](https://pptr.dev/contributing) to get an
|
|
|
|
|
overview of Puppeteer development.
|
2018-04-17 17:57:21 +00:00
|
|
|
|
2022-07-01 11:52:39 +00:00
|
|
|
## FAQ
|
2018-04-17 17:57:21 +00:00
|
|
|
|
2022-10-17 11:07:41 +00:00
|
|
|
Our [FAQ](https://pptr.dev/faq) has migrated to
|
|
|
|
|
[our site](https://pptr.dev/faq).
|
