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