|
3 | 3 | ## Prepare
|
4 | 4 |
|
5 | 5 | 1. `npm run browser-test` - Ensure build steps occur and tests are passing
|
6 |
| -1. `npm test` - This should also be run, though currently accessibility tests |
7 |
| - are failing |
8 |
| -1. `npm run build-doc` - Ensure JSDoc can build and is available for site |
| 6 | +1. `npm start` and in another console window, `npm test` - This should |
| 7 | + also be run, though currently accessibility tests are failing. |
| 8 | +1. `npm run build-docs` - Ensure JSDoc can build and is available for site |
9 | 9 | build (though not added to `master`, will be copied over in `gh-pages`
|
10 | 10 | steps and used in `npm publish` step).
|
11 |
| -1. `npm run types-doc` - For JSDoc, we ensure that a minimum of generic types |
| 11 | +1. `npm run types-docs` - For JSDoc, we ensure that a minimum of generic types |
12 | 12 | have been added (e.g., "number" should instead be "Float" or "Array",
|
13 | 13 | and "object", "function", or "array" should be replaced by more specific
|
14 | 14 | `@interface`s, `@typdef`s, or `@callback`. Deriving types can use
|
15 | 15 | `PlainObject` or `GenericArray` to indicate the simple base type was
|
16 | 16 | intentional. `*` should also be checked. The script reports all failing
|
17 | 17 | matches within `editor`. There should be none (there is currently one
|
18 | 18 | due to our needing to move the file to its own module).
|
19 |
| -1. `npm pack` to preview which files will be included once published and |
20 |
| - taking into account `.npmignore`. Take care to remove the `.tgz` tarball |
21 |
| - file that it creates so it is not itself included during the |
22 |
| - publishing step. |
| 19 | +1. `npm pack --dry-run` to preview which files will be included once |
| 20 | + published and taking into account `.npmignore`. |
23 | 21 |
|
24 | 22 | ## Update the main project
|
25 | 23 | <!--
|
|
30 | 28 | 1. Add new release info to `Recent news` section in README
|
31 | 29 | 1. Commit these changes
|
32 | 30 | <!-- with `git commit -m "Updating Makefile and CHANGES for release X.Y.Z"`-->.
|
33 |
| -1. Tag the version, prefixed by "v", e.g., `v4.0.1`. |
| 31 | +1. Tag the version, prefixed by "v", e.g., `v5.0.1`. |
34 | 32 |
|
35 | 33 | The above steps can be done on a fork and committed via a pull request.
|
36 | 34 |
|
|
0 commit comments