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
2023-04-21 12:07:10 +00:00
> [headless](https://developer.chrome.com/articles/new-headless/)
2023-05-02 06:53:40 +00:00
> mode by default, but can be configured to run in full ("headful")
2022-10-17 11:07:41 +00:00
> 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.
2023-04-05 16:06:33 +00:00
- [Test Chrome Extensions ](https://pptr.dev/guides/chrome-extensions ).
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
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
2023-04-05 16:06:33 +00:00
# or using yarn
yarn add puppeteer
# or using pnpm
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
2023-12-07 10:00:20 +00:00
[Chrome for Testing ](https://developer.chrome.com/blog/chrome-for-testing/ ) (~170MB macOS, ~282MB Linux, ~280MB Windows) and a `chrome-headless-shell` binary (starting with Puppeteer v21.6.0) that is [guaranteed to
2023-02-17 08:27:58 +00:00
work](https://pptr.dev/faq#q-why-doesnt-puppeteer-vxxx-work-with-chromium-vyyy)
with Puppeteer. The browser is downloaded to the `$HOME/.cache/puppeteer` folder
2023-12-07 10:00:20 +00:00
by default (starting with Puppeteer v19.0.0). See [configuration ](https://pptr.dev/api/puppeteer.configuration ) for configuration options and environmental variables to control the download behavor.
2023-02-17 08:27:58 +00:00
If you deploy a project using Puppeteer to a hosting provider, such as Render or
Heroku, you might need to reconfigure the location of the cache to be within
your project folder (see an example below) because not all hosting providers
include `$HOME/.cache` into the project's deployment.
For a version of Puppeteer without the browser installation, see
2022-10-17 11:07:41 +00:00
[`puppeteer-core` ](#puppeteer-core ).
2017-06-19 23:37:55 +00:00
2023-07-21 07:03:55 +00:00
If used with TypeScript, the minimum supported TypeScript version is `4.7.4` .
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
2023-10-24 07:23:50 +00:00
For every release since v1.7.0 we publish two packages:
2022-07-01 11:52:39 +00:00
- [`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
2023-05-02 06:53:40 +00:00
a version of Chrome, 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`
2023-05-02 06:53:40 +00:00
will not download Chrome when installed.
2022-10-24 07:07:05 +00:00
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 )
2023-05-04 08:24:04 +00:00
or [managing browsers yourself ](https://pptr.dev/browsers-api/ ).
2022-10-28 06:49:28 +00:00
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
2023-10-24 07:23:50 +00:00
an explicit
2023-03-29 09:37:35 +00:00
[`executablePath` ](https://pptr.dev/api/puppeteer.launchoptions )
(or [`channel` ](https://pptr.dev/api/puppeteer.launchoptions ) if it's
2022-10-28 06:49:28 +00:00
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
2023-01-17 15:04:48 +00:00
The following example searches [developer.chrome.com ](https://developer.chrome.com/ ) for blog posts with text "automate beyond recorder", click on the first result and print the full title of the blog post.
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 () => {
2023-07-14 09:37:17 +00:00
// Launch the browser and open a new blank page
2017-08-24 16:13:49 +00:00
const browser = await puppeteer.launch();
const page = await browser.newPage();
2023-07-14 09:37:17 +00:00
// Navigate the page to a URL
2023-01-17 15:04:48 +00:00
await page.goto('https://developer.chrome.com/');
2017-08-24 16:13:49 +00:00
2023-01-17 15:04:48 +00:00
// Set screen size
await page.setViewport({width: 1080, height: 1024});
2018-03-07 05:50:06 +00:00
2023-01-17 15:04:48 +00:00
// Type into search box
await page.type('.search-box__input', 'automate beyond recorder');
2022-08-05 09:00:09 +00:00
2023-01-17 15:04:48 +00:00
// Wait and click on first result
const searchResultSelector = '.search-box__link';
await page.waitForSelector(searchResultSelector);
await page.click(searchResultSelector);
2022-08-05 09:00:09 +00:00
2023-01-31 09:15:58 +00:00
// Locate the full title with a unique string
2023-01-17 15:04:48 +00:00
const textSelector = await page.waitForSelector(
'text/Customize and automate'
);
2023-05-08 10:38:16 +00:00
const fullTitle = await textSelector?.evaluate(el => el.textContent);
2022-07-01 11:52:39 +00:00
2023-01-17 15:04:48 +00:00
// Print the full title
console.log('The title of this blog post is "%s".', fullTitle);
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
2023-05-02 06:53:40 +00:00
By default Puppeteer launches Chrome in
2023-04-21 12:07:10 +00:00
[old Headless mode ](https://developer.chrome.com/articles/new-headless/ ).
```ts
const browser = await puppeteer.launch();
// Equivalent to
const browser = await puppeteer.launch({headless: true});
```
[Chrome 112 launched a new Headless mode ](https://developer.chrome.com/articles/new-headless/ ) that might cause some differences in behavior compared to the old Headless implementation.
In the future Puppeteer will start defaulting to new implementation.
We recommend you try it out before the switch:
```ts
const browser = await puppeteer.launch({headless: 'new'});
```
2023-05-02 06:53:40 +00:00
To launch a "headful" version of Chrome, set the
2023-04-24 06:29:28 +00:00
[`headless` ](https://pptr.dev/api/puppeteer.browserlaunchargumentoptions ) to `false`
2022-10-17 11:07:41 +00:00
option when launching a browser:
2017-08-11 01:31:54 +00:00
2022-07-01 11:52:39 +00:00
```ts
2023-04-21 12:07:10 +00:00
const browser = await puppeteer.launch({headless: false});
2017-08-11 01:31:54 +00:00
```
2023-05-02 06:53:40 +00:00
**2. Runs a bundled version of Chrome**
2017-06-20 02:17:11 +00:00
2023-05-02 06:53:40 +00:00
By default, Puppeteer downloads and uses a specific version of Chrome so its
2022-10-17 11:07:41 +00:00
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
```
2023-04-20 07:05:41 +00:00
You can also use Puppeteer with Firefox. See
[status of cross-browser support ](https://pptr.dev/faq/#q-what-is-the-status-of-cross-browser-support ) for
2022-10-17 11:07:41 +00:00
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 ).
