e655bb6ca2
The `Puppeteer` class had two concerns: * connect to an existing browser * launch a new browser The first of those concerns is needed in all environments, but the second is only needed in Node. https://github.com/puppeteer/puppeteer/pull/6484 landing enabled us to pull the `Puppeteer` class apart into two: 1. `Puppeteer` which hosts the behaviour for connecting to existing browsers. 2. `PuppeteerNode`, which extends `Puppeteer` and also adds the ability to launch a new browser. This is a non-breaking change, because Node users will still get an instance of a class with all the methods they expect, but it'll be a `PuppeteerNode` rather than `Puppeteer`. I don't expect this to cause people any issues. We also now have new files that are effectively the entry points for Puppeteer: * `node.ts`: the main entry point for Puppeteer on Node. * `web.ts`: the main entry point for Puppeteer on the web. * `node-puppeteer-core.ts`: for those using puppeteer-core (which only exists in Node, not on the web).
22 lines
747 B
Markdown
22 lines
747 B
Markdown
<!-- Do not edit this file. It is automatically generated by API Documenter. -->
|
|
|
|
[Home](./index.md) > [puppeteer](./puppeteer.md) > [PuppeteerNode](./puppeteer.puppeteernode.md) > [executablePath](./puppeteer.puppeteernode.executablepath.md)
|
|
|
|
## PuppeteerNode.executablePath() method
|
|
|
|
<b>Signature:</b>
|
|
|
|
```typescript
|
|
executablePath(): string;
|
|
```
|
|
<b>Returns:</b>
|
|
|
|
string
|
|
|
|
A path where Puppeteer expects to find the bundled browser. The browser binary might not be there if the download was skipped with the `PUPPETEER_SKIP_DOWNLOAD` environment variable.
|
|
|
|
## Remarks
|
|
|
|
\*\*NOTE\*\* `puppeteer.executablePath()` is affected by the `PUPPETEER_EXECUTABLE_PATH` and `PUPPETEER_CHROMIUM_REVISION` environment variables.
|
|
|