You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+30-18
Original file line number
Diff line number
Diff line change
@@ -3,8 +3,8 @@
3
3
Thanks for your interest in contributing to Plotly.js! We are actively looking for
4
4
diverse contributors, with diverse background and skills.
5
5
6
-
This document outlines the general way that changes get made to this library and by whom,
7
-
and then provides specific technical information about how to set up a development
6
+
This document outlines the general way that changes get made to this library and by whom,
7
+
and then provides specific technical information about how to set up a development
8
8
environment for doing development and running tests.
9
9
10
10
## Code of Conduct
@@ -25,7 +25,7 @@ The basic architecture of Plotly.js is to accept [JSON](https://json.org/) repre
25
25
The basic process for adding new features or fixing bugs is as follows. Please note that this is a bit of an idealized outline and that things often don't proceed in a clean/linear fashion and that's ok :)
26
26
27
27
1.**Discussion** - A community member or maintainer creates an issue to discuss the use-case for the new feature. This usually entails describing the desired graphical output and discussing how close the current system can get to specifying or drawing such a figure. If the issue is perceived to be a bug, the discussion revolves around understanding how the current behaviour is incorrect or problematic, and how existing users of the system would be impacted by a change in this behaviour.
28
-
2.**Proposal** - If the current system cannot specify or draw such a figure, or if the way to do it is too onerous, a good next step would be to discuss or propose a specific change to the schema: new attributes to be added or new accepted values to new attributes, along with a prose description of the proposed drawing code. If the issue is determined to be a bug rather than a feature, the same type of proposal is required: a definition of which attributes and values will be impacted by the proposed change. A good proposal includes discussion of whether or not existing attributes can be modified rather than adding new attributes and details about which trace types or subplot types are impacted by the change. Note: sometimes community contributors skip this step and go straight to development & review (below), but going through a proposal can help speed along the review process!
28
+
2.**Proposal** - If the current system cannot specify or draw such a figure, or if the way to do it is too onerous, a good next step would be to discuss or propose a specific change to the schema: new attributes to be added or new accepted values to new attributes, along with a prose description of the proposed drawing code. If the issue is determined to be a bug rather than a feature, the same type of proposal is required: a definition of which attributes and values will be impacted by the proposed change. A good proposal includes discussion of whether or not existing attributes can be modified rather than adding new attributes and details about which trace types or subplot types are impacted by the change. Note: sometimes community contributors skip this step and go straight to development & review (below), but going through a proposal can help speed along the review process!
29
29
3.**Iteration** - The maintainers of the library or any other interested community member will then give feedback on the proposal, usually focused on consistency with the rest of the schema, and helping define a test plan to further elaborate potential edge cases.
30
30
4.**Approval** - After a number of iterations, the maintainers of the library will generally approve a proposal with an informal "this seems like something we would accept a pull request for" comment in the issue.
31
31
5.**Development** - A community member or maintainer creates a branch and makes the appropriate modifications to the code and tests and opens a pull request. This can be more or less time-consuming and challenging, depending on the nature of the change.
@@ -207,23 +207,35 @@ npm run test-jasmine -- --help
207
207
npm run test-jasmine -- --info
208
208
```
209
209
210
-
### Image pixel comparison tests
211
-
212
-
Image pixel comparison tests are run in a docker container. For more
213
-
information on how to run them locally, please refer to [image test
Running the test locally outputs the generated png images in `build/test_images/` and the png diffs in `build/test_images_diff/` (two git-ignored directories).
217
-
218
-
To view the image pixel comparison test results, run
which shows the baseline image, the generated image, the diff and the json mocks of test cases that failed.
225
222
226
-
To view the results of a run on CircleCI, download the `build/test_images/` and `build/test_images_diff/` artifacts into your local repo and then run `npm run start-image_viewer`.
223
+
**IMPORTANT:** the `baseline`, `test-image` and `test-export` scripts do **not** bundle the source files before
224
+
running the image tests. We recommend running `npm run watch` or `npm start` in
225
+
a separate tab to ensure that the most up-to-date code is used.
226
+
Also if you are adding a new mock, you may need to re-run `npm start` or `npm run watch`
227
+
to be able to find the new mock in the browser.
228
+
To help ensure valid attributes are used in your new mock(s), please run `npm run test-mock`
229
+
or `npm run test-mock mock_name(s)` after adding new mocks or implementing any new attributes.
230
+
231
+
If you added new mocks to test/image/mocks folder, to generate draft baselines run
0 commit comments