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
+21-22Lines changed: 21 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -196,16 +196,29 @@ This section outlines the strategy for managing dependencies to maintain stabili
196
196
197
197
### Dependency Categories and Update Cadence
198
198
199
-
#### 1. Peer Dependencies (`sdk/package.json`)
199
+
#### 1. Peer Dependencies (`starter-peer-deps`)
200
200
201
-
These are the most critical dependencies (`wrangler`, `@cloudflare/vite-plugin`, etc.). Our process is designed to test the boundaries of our allowed `peerDependencies` version range.
201
+
- **What**: The most critical dependencies (`wrangler`, `react`, `vite`, etc.) that are defined as `peerDependencies` in the SDK and tested in the `starters/*` projects.
202
+
- **When**: As Soon As Possible (ASAP). Renovate creates a PR immediately when a new version is available.
203
+
- **Why**: To provide an immediate early-warning signal if a new peer dependency version introduces a regression that could affect users.
202
204
203
-
- **Update Cadence**: "As Soon As Possible" (ASAP).
204
-
- **Process**:
205
-
1. **Testing New Versions**: An automated process opens a Pull Request to update the versions of these dependencies in our `starters/*` projects to the *latest available version* that still satisfies the SDK's `peerDependencies` range. This is how we define a "peer dependency update"in our context.
206
-
2. **CI Signal**: This PR triggers our full smoke test suite. The CI result is the signal.
207
-
3. **If CI passes**, the PR can be manually reviewed and merged. This indicates the new version is safe.
208
-
4. **If CI fails**, it triggers the failure protocol below.
- **What**: All non-peer dependencies in the `starters/*` projects.
214
+
- **When**: Weekly, in a single grouped pull request.
215
+
- **Why**: To ensure our starter templates remain current with their own dependencies.
216
+
217
+
#### 4. Repository, Docs, and Infrastructure Dependencies (`docs-and-infra-deps`)
218
+
219
+
- **What**: A consolidated group for all remaining repository maintenance dependencies. This includes dependencies from the root `package.json`, the `docs/package.json`, GitHub Actions, Docker images, and the `.node-version` file.
220
+
- **When**: Weekly, in a single grouped pull request.
221
+
- **Why**: To bundle all miscellaneous tooling, documentation, and infrastructure updates into one convenient PR to reduce noise.
209
222
210
223
### Failure Protocol for Peer Dependencies
211
224
@@ -224,20 +237,6 @@ When the smoke tests fail on a peer dependency update, it is a signal that requi
224
237
225
238
* Once CI passes on the PR, it can be merged. This prepares for a patch release of `rwsdk` that protects users from the faulty dependency.
These are the `dependencies` and `devDependencies` used to build the SDK itself.
230
-
231
-
- **Update Cadence**: Weekly.
232
-
- **Process**: A single, grouped Pull Request will be opened each week with all available updates. This PR must pass the smoke test suite before being manually merged. Security-related updates are handled immediately in separate PRs.
These are dependencies in our starter projects that are not peer dependencies of the SDK.
237
-
238
-
- **Update Cadence**: Weekly.
239
-
- **Process**: Handled in a single, grouped weekly PR, validated by smoke tests.
240
-
241
240
## Debugging changes to the sdk locally for a project
242
241
243
242
The `rwsync` command provides a bridge between a local checkout of the `rwsdk` and a project that uses it, enabling a fast and efficient development workflow.
0 commit comments