Update preview build instructions #7588
Open
+251
−93
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Most of the contributor docs are kept in one main file, but as time as gone on we have split out specific topics into their own files. Some files are not linked from the main file at all. Finally, one of the files in `docs/` is intended for the `core-backend` repo, not the repo as a whole. Ultimately, this is confusing for contributors. This commit converts the main file to a table of contents, organized by category, and makes sure to link to every file in `docs/`. It also moves the `core-backend`-specific file to that package.
Co-authored-by: Maarten Zuidhoorn <[email protected]>
Preview builds are represented as prereleases, which means that care must be taken to accurately simulate what the dependency tree of a project will look like when a new production version is released. Unfortunately, the existing instructions for using preview builds do not achieve this. This problem has always existed but was exacerbated by the recent shift from peer dependencies to dependencies. This commit updates the instructions to fix these issues. There are now separate instructions for testing breaking changes vs. non-breaking changes. An addendum for working with patches, which was missing before, is also now included. Finally, instructions for using local builds has been split off from the preview builds instructions for ease of readability.
mcmire
force-pushed
the
update-preview-builds-instructions
branch
from
97c9bbf to
a04b461
Compare
mcmire
changed the title
mcmire
commented
Jan 12, 2026
|
|
||
| 1. In the project, open `package.json` and locate the entry in `dependencies` for the package. Take note of the major part of the version. | ||
|
|
||
| 2. Run `yarn why @metamask/<PACKAGE_NAME>`, replacing `PACKAGE_NAME` as appropriate. You will see output like this: |
Contributor
Author
There was a problem hiding this comment.
This is a new process that I'm introducing in this PR. The previous process recommended that the engineer look at the existing dependency entry and target whatever version range was used there. Now I'm recommended that all version ranges in the dependency tree that are compatible with the one used in the dependency tree are targeted. As I mention at the top of this section, this is to mimic production as close as possible.
So on one hand, it's more accurate. On the other hand, it's more steps that before. Do we have any thoughts on this? It would nice if we could automate this somehow, but I'm not sure how to do that yet.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation
Preview builds are represented as prereleases, which means that care must be taken to accurately simulate what the dependency tree of a project will look like when a new production version is released. Unfortunately, the existing instructions for using preview builds do not achieve this. This problem has always existed but was exacerbated by the recent shift from peer dependencies to dependencies.
This commit updates the instructions to fix these issues. There are now separate instructions for testing breaking changes vs. non-breaking changes. An addendum for working with patches, which was missing before, is also now included. Finally, instructions for using local builds has been split off from the preview builds instructions for ease of readability.
References
Checklist
Note
Refactors and expands documentation around testing unreleased packages.
docs/processes/preview-builds.mdwith detailed workflows for publishing/using preview builds, including separate paths for breaking vs. non‑breaking changes and handling patched dependenciesdocs/processes/local-builds.mdand trimstesting-changes-in-other-projects.mdto link to the two optionsbreaking-changes.mdto point topreview-builds.mdscripts/generate-preview-build-message.tsto link to the new preview builds docWritten by Cursor Bugbot for commit bc09a6a. This will update automatically on new commits. Configure here.