1 |
|
2 | - [How to Contribute](#how-to-contribute)
|
3 | * [Contributor License Agreement](#contributor-license-agreement)
|
4 | * [Getting Code](#getting-code)
|
5 | * [Code reviews](#code-reviews)
|
6 | * [Code Style](#code-style)
|
7 | * [API guidelines](#api-guidelines)
|
8 | * [Commit Messages](#commit-messages)
|
9 | * [Writing Documentation](#writing-documentation)
|
10 | * [Adding New Dependencies](#adding-new-dependencies)
|
11 | * [Running & Writing Tests](#running--writing-tests)
|
12 | * [Public API Coverage](#public-api-coverage)
|
13 | * [Debugging Puppeteer](#debugging-puppeteer)
|
14 | - [For Project Maintainers](#for-project-maintainers)
|
15 | * [Releasing to npm](#releasing-to-npm)
|
16 | * [Updating npm dist tags](#updating-npm-dist-tags)
|
17 |
|
18 |
|
19 | # How to Contribute
|
20 |
|
21 | First of all, thank you for your interest in Puppeteer!
|
22 | We'd love to accept your patches and contributions!
|
23 |
|
24 | ## Contributor License Agreement
|
25 |
|
26 | Contributions to this project must be accompanied by a Contributor License
|
27 | Agreement. You (or your employer) retain the copyright to your contribution,
|
28 | this simply gives us permission to use and redistribute your contributions as
|
29 | part of the project. Head over to <https://cla.developers.google.com/> to see
|
30 | your current agreements on file or to sign a new one.
|
31 |
|
32 | You generally only need to submit a CLA once, so if you've already submitted one
|
33 | (even if it was for a different project), you probably don't need to do it
|
34 | again.
|
35 |
|
36 | ## Getting Code
|
37 |
|
38 | 1. Clone this repository
|
39 |
|
40 | ```bash
|
41 | git clone https://github.com/GoogleChrome/puppeteer
|
42 | cd puppeteer
|
43 | ```
|
44 |
|
45 | 2. Install dependencies
|
46 |
|
47 | ```bash
|
48 | npm install
|
49 | ```
|
50 |
|
51 | 3. Run Puppeteer tests locally. For more information about tests, read [Running & Writing Tests](#running--writing-tests).
|
52 |
|
53 | ```bash
|
54 | npm run unit
|
55 | ```
|
56 |
|
57 | ## Code reviews
|
58 |
|
59 | All submissions, including submissions by project members, require review. We
|
60 | use GitHub pull requests for this purpose. Consult
|
61 | [GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
|
62 | information on using pull requests.
|
63 |
|
64 | ## Code Style
|
65 |
|
66 | - Coding style is fully defined in [.eslintrc](https://github.com/GoogleChrome/puppeteer/blob/master/.eslintrc.js)
|
67 | - Code should be annotated with [closure annotations](https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler).
|
68 | - Comments should be generally avoided. If the code would not be understood without comments, consider re-writing the code to make it self-explanatory.
|
69 |
|
70 | To run code linter, use:
|
71 |
|
72 | ```bash
|
73 | npm run lint
|
74 | ```
|
75 |
|
76 | ## API guidelines
|
77 |
|
78 | When authoring new API methods, consider the following:
|
79 |
|
80 | - Expose as little information as needed. When in doubt, don’t expose new information.
|
81 | - Methods are used in favor of getters/setters.
|
82 | - The only exception is namespaces, e.g. `page.keyboard` and `page.coverage`
|
83 | - All string literals must be small case. This includes event names and option values.
|
84 | - Avoid adding "sugar" API (API that is trivially implementable in user-space) unless they're **very** demanded.
|
85 |
|
86 | ## Commit Messages
|
87 |
|
88 | Commit messages should follow the Semantic Commit Messages format:
|
89 |
|
90 | ```
|
91 | label(namespace): title
|
92 |
|
93 | description
|
94 |
|
95 | footer
|
96 | ```
|
97 |
|
98 | 1. *label* is one of the following:
|
99 | - `fix` - puppeteer bug fixes.
|
100 | - `feat` - puppeteer features.
|
101 | - `docs` - changes to docs, e.g. `docs(api.md): ..` to change documentation.
|
102 | - `test` - changes to puppeteer tests infrastructure.
|
103 | - `style` - puppeteer code style: spaces/alignment/wrapping etc.
|
104 | - `chore` - build-related work, e.g. doclint changes / travis / appveyor.
|
105 | 2. *namespace* is put in parenthesis after label and is optional. Must be lowercase.
|
106 | 3. *title* is a brief summary of changes.
|
107 | 4. *description* is **optional**, new-line separated from title and is in present tense.
|
108 | 5. *footer* is **optional**, new-line separated from *description* and contains "fixes" / "references" attribution to github issues.
|
109 | 6. *footer* should also include "BREAKING CHANGE" if current API clients will break due to this change. It should explain what changed and how to get the old behavior.
|
110 |
|
111 | Example:
|
112 |
|
113 | ```
|
114 | fix(page): fix page.pizza method
|
115 |
|
116 | This patch fixes page.pizza so that it works with iframes.
|
117 |
|
118 | Fixes #123, Fixes #234
|
119 |
|
120 | BREAKING CHANGE: page.pizza now delivers pizza at home by default.
|
121 | To deliver to a different location, use "deliver" option:
|
122 | `page.pizza({deliver: 'work'})`.
|
123 | ```
|
124 |
|
125 | ## Writing Documentation
|
126 |
|
127 | All public API should have a descriptive entry in [`docs/api.md`](https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md). There's a [documentation linter](https://github.com/GoogleChrome/puppeteer/tree/master/utils/doclint) which makes sure documentation is aligned with the codebase.
|
128 |
|
129 | To run the documentation linter, use:
|
130 |
|
131 | ```bash
|
132 | npm run doc
|
133 | ```
|
134 |
|
135 | ## Adding New Dependencies
|
136 |
|
137 | For all dependencies (both installation and development):
|
138 | - **Do not add** a dependency if the desired functionality is easily implementable.
|
139 | - If adding a dependency, it should be well-maintained and trustworthy.
|
140 |
|
141 | A barrier for introducing new installation dependencies is especially high:
|
142 | - **Do not add** installation dependency unless it's critical to project success.
|
143 |
|
144 | ## Running & Writing Tests
|
145 |
|
146 | - Every feature should be accompanied by a test.
|
147 | - Every public api event/method should be accompanied by a test.
|
148 | - Tests should be *hermetic*. Tests should not depend on external services.
|
149 | - Tests should work on all three platforms: Mac, Linux and Win. This is especially important for screenshot tests.
|
150 |
|
151 | Puppeteer tests are located in [`test/test.js`](https://github.com/GoogleChrome/puppeteer/blob/master/test/test.js)
|
152 | and are written with a [TestRunner](https://github.com/GoogleChrome/puppeteer/tree/master/utils/testrunner) framework.
|
153 | Despite being named 'unit', these are integration tests, making sure public API methods and events work as expected.
|
154 |
|
155 | - To run all tests:
|
156 |
|
157 | ```bash
|
158 | npm run unit
|
159 | ```
|
160 |
|
161 | - To run tests in parallel, use `-j` flag:
|
162 |
|
163 | ```bash
|
164 | npm run unit -- -j 4
|
165 | ```
|
166 |
|
167 | - To run tests in "verbose" mode or to stop testrunner on first failure:
|
168 |
|
169 | ```bash
|
170 | npm run unit -- --verbose
|
171 | npm run unit -- --break-on-failure
|
172 | ```
|
173 |
|
174 | - To run a specific test, substitute the `it` with `fit` (mnemonic rule: '*focus it*'):
|
175 |
|
176 | ```js
|
177 | ...
|
178 | // Using "fit" to run specific test
|
179 | fit('should work', async function({server, page}) {
|
180 | const response = await page.goto(server.EMPTY_PAGE);
|
181 | expect(response.ok).toBe(true);
|
182 | });
|
183 | ```
|
184 |
|
185 | - To disable a specific test, substitute the `it` with `xit` (mnemonic rule: '*cross it*'):
|
186 |
|
187 | ```js
|
188 | ...
|
189 | // Using "xit" to skip specific test
|
190 | xit('should work', async function({server, page}) {
|
191 | const response = await page.goto(server.EMPTY_PAGE);
|
192 | expect(response.ok).toBe(true);
|
193 | });
|
194 | ```
|
195 |
|
196 | - To run tests in non-headless mode:
|
197 |
|
198 | ```bash
|
199 | HEADLESS=false npm run unit
|
200 | ```
|
201 |
|
202 | - To run tests with custom Chromium executable:
|
203 |
|
204 | ```bash
|
205 | CHROME=<path-to-executable> npm run unit
|
206 | ```
|
207 |
|
208 | - To run tests in slow-mode:
|
209 |
|
210 | ```bash
|
211 | HEADLESS=false SLOW_MO=500 npm run unit
|
212 | ```
|
213 |
|
214 | - To debug a test, "focus" a test first and then run:
|
215 |
|
216 | ```bash
|
217 | node --inspect-brk test/test.js
|
218 | ```
|
219 |
|
220 | ## Public API Coverage
|
221 |
|
222 | Every public API method or event should be called at least once in tests. To ensure this, there's a `coverage` command which tracks calls to public API and reports back if some methods/events were not called.
|
223 |
|
224 | Run coverage:
|
225 |
|
226 | ```bash
|
227 | npm run coverage
|
228 | ```
|
229 |
|
230 | ## Debugging Puppeteer
|
231 |
|
232 | See [Debugging Tips](README.md#debugging-tips) in the readme.
|
233 |
|
234 | # For Project Maintainers
|
235 |
|
236 | ## Releasing to npm
|
237 |
|
238 | Releasing to npm consists of the following phases:
|
239 |
|
240 | 1. Source Code: mark a release.
|
241 | 1. Bump `package.json` version following the SEMVER rules, run `npm run doc` to update the docs accordingly, and send a PR titled `'chore: mark version vXXX.YYY.ZZZ'` ([example](https://github.com/GoogleChrome/puppeteer/commit/808bf8e5582482a1d849ff22a51e52024810905c)).
|
242 | 2. Make sure the PR passes **all checks**.
|
243 | - **WHY**: there are linters in place that help to avoid unnecessary errors, e.g. [like this](https://github.com/GoogleChrome/puppeteer/pull/2446)
|
244 | 3. Merge the PR.
|
245 | 4. Once merged, publish the release notes using [GitHub's "draft new release tag" option](https://github.com/GoogleChrome/puppeteer/releases/new).
|
246 | - **NOTE**: tag names are prefixed with `'v'`, e.g. for version `1.4.0` the tag is `v1.4.0`.
|
247 | - For the "raw notes" section, use `git log --pretty="%h - %s" v1.19.0..HEAD`.
|
248 | 5. Update the “Releases per Chromium Version” list in [`docs/api.md`](https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md) to include the new version.
|
249 | 2. Publish `puppeteer` to npm.
|
250 | 1. On your local machine, pull from [upstream](https://github.com/GoogleChrome/puppeteer) and make sure the last commit is the one just merged.
|
251 | 2. Run `git status` and make sure there are no untracked files.
|
252 | - **WHY**: this is to avoid adding unnecessary files to the npm package.
|
253 | 3. Run [`npx pkgfiles`](https://www.npmjs.com/package/pkgfiles) to make sure you don't publish anything unnecessary.
|
254 | 4. Run `npm publish`. This publishes the `puppeteer` package.
|
255 | 3. Publish `puppeteer-core` to npm.
|
256 | 1. Run `./utils/prepare_puppeteer_core.js`. The script changes the name inside `package.json` to `puppeteer-core`.
|
257 | 2. Run `npm publish`. This publishes the `puppeteer-core` package.
|
258 | 3. Run `git reset --hard` to reset the changes to `package.json`.
|
259 | 4. Source Code: mark post-release.
|
260 | 1. Bump `package.json` version to `-post` version and send a PR titled `'chore: bump version to vXXX.YYY.ZZZ-post'` ([example](https://github.com/GoogleChrome/puppeteer/commit/d02440d1eac98028e29f4e1cf55413062a259156))
|
261 | - **NOTE**: make sure to update the "released APIs" section in the top of `docs/api.md` by running `npm run doc`.
|
262 | - **NOTE**: no other commits should be landed in-between release commit and bump commit.
|
263 |
|
264 | ## Updating npm dist tags
|
265 |
|
266 | For both `puppeteer` and `puppeteer-core` we maintain the following npm tags:
|
267 |
|
268 | - `chrome-*` tags, e.g. `chrome-75` and so on. These tags match the Puppeteer version that corresponds to the `chrome-*` release.
|
269 | - `chrome-stable` tag. This tag points to the Puppeteer version that works with the current Chrome stable release.
|
270 |
|
271 | These tags are updated on every Puppeteer release.
|
272 |
|
273 | > **NOTE**: due to Chrome's rolling release, we take [omahaproxy's linux stable version](https://omahaproxy.appspot.com/) as *stable*.
|
274 |
|
275 | Managing tags 101:
|
276 |
|
277 | ```bash
|
278 | # list tags
|
279 | $ npm dist-tag ls puppeteer
|
280 | # Removing a tag
|
281 | $ npm dist-tag rm puppeteer-core chrome-stable
|
282 | # Adding a tag
|
283 | $ npm dist-tag add puppeteer-core@1.13.0 chrome-stable
|
284 | ```
|