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
"post-versioning": "echo 'This will take a while...' && npm run bump-peer-deps && npm run refresh-node-modules && npm run commit-package-changes && npm run update-version-tags",
Copy file name to clipboardExpand all lines: packages/docs/docs/contributing.md
+39-11
Original file line number
Diff line number
Diff line change
@@ -29,6 +29,22 @@ If that is the situation for you, you can instead use `npm run build-serial` to
29
29
Also, if you are only working on one package, you can `npm run build` and `npm run test` from within the subdirectory.
30
30
Finally, you can simply `npm start` inside of the `playground` directory to test changes if you have already built all of your packages, without needing to watch all of the packages via the root directory `npm start`.
31
31
32
+
### Troubleshooting build failures
33
+
34
+
Sometimes your local builds fail and you can't figure out why. This is most likely to happen after rebase to `main` due
35
+
to `package.json` changes upstream. There are two commands you can use to (hopefully) get your environment back to a
36
+
working state. Try running the following two commands:
37
+
38
+
```bash
39
+
npm run refresh-node-modules
40
+
npm run clean-build
41
+
```
42
+
43
+
The first command will delete all of the `node_modules` directories in the environment and then rerun `npm install`.
44
+
The second command cleans up the typescript build cache files before retrying the build.
45
+
46
+
Worst case scenario when neither of those commands work, try running `npm run nuke-build-env` and then rerun the two commands.
47
+
32
48
## Cloud builds
33
49
34
50
When building in environments with limited memory, such as Netlify, it's recommended to use `npm run build-serial` that builds the packages serially.
@@ -123,7 +139,7 @@ Code coverage reports are currently available only for the `@rjsf/core` theme pa
123
139
They are generated using [nyc](https://github.com/istanbuljs/nyc) each time the `npm test-coverage` script is run.
124
140
The full report can be seen by opening `./coverage/lcov-report/index.html`.
125
141
126
-
#### Utils and validator-ajvX code coverage
142
+
#### Utils and validator-ajv8 code coverage
127
143
128
144
100% code coverage is required by the `@rjsf/utils` and `@rjsf/validator-ajv8` tests.
129
145
If you make changes to those libraries, you will have to maintain that coverage, otherwise the tests will fail.
@@ -133,23 +149,20 @@ If you make changes to those libraries, you will have to maintain that coverage,
133
149
## Releasing
134
150
135
151
To release, go to the main branch (NOT a fork) and then create a new branch with the version number (with an `rc` prefix instead of `v`).
136
-
For instance if you are about to create the new `5.100.10` branch, then you would run the following commands:
152
+
For instance if you are about to create the new `6.100.10` branch, then you would run the following commands:
137
153
138
154
```bash
139
155
git checkout -b rc6.100.10
140
-
git push
141
156
npx nx release version --git-tag
142
-
npm run post-versioning
157
+
git commit -m "Releasing 6.100.10"
158
+
git push
159
+
npm run update-version-tags
143
160
```
144
161
145
162
Make sure you use [semver](https://semver.org/) for version numbering when selecting the version.
146
-
The `npx nx release version --git-tag` command will create a new version tag and push it to GitHub.
147
-
148
-
The `npm run post-versioning` script will update the peer dependencies in all of the `packages/*/package.json` files if necessary.
149
-
It will then clean up the `node_modules` directories and rerun `npm install` to update the `package-lock.json` files.
150
-
Finally, it creates and pushes a new commit with those `package.json` and `package-lock.json` files up to GitHub.
151
-
152
-
> NOTE: this command will take a while, be patient
163
+
The `npx nx release version --git-tag` command will update the `package*.josn` files and create a new version tag.
164
+
Committing and pushing the branch will allow you to create the PR on GitHub.
165
+
The `npm run update-version-tags` will push the tags up to GitHub.
153
166
154
167
Then, make a PR to main. Merge the PR into main -- make sure you use "merge commit", not squash and merge, so that
155
168
the original commit where the tag was based on is still present in the main branch.
@@ -164,6 +177,21 @@ The package is published through an automation token belonging to the
164
177
[rjsf-bot](https://www.npmjs.com/~rjsf-bot) user on npm. This token
165
178
is stored as the `NPM_TOKEN` secret on GitHub Actions.
166
179
180
+
### Updating the peer dependencies for new features in a minor release
181
+
182
+
If a set of changes added new features or APIs that require updating downstream peer dependencies, then run the following
183
+
command:
184
+
185
+
```bash
186
+
npm run post-versioning
187
+
```
188
+
189
+
The `npm run post-versioning` script will update the peer dependencies in all of the `packages/*/package.json` files if necessary.
190
+
It will then clean up the `node_modules` directories and rerun `npm install` to update the `package-lock.json` files.
191
+
Finally, it creates and pushes a new commit with those `package.json` and `package-lock.json` files up to GitHub.
192
+
193
+
> NOTE: this command will take a while, be patient
194
+
167
195
### Releasing docs
168
196
169
197
Docs are automatically published to GitHub Pages when the `main` branch is updated.
0 commit comments