Repository navigation
[opencode] chore: drop vendored got patch for a got resolution - #102
Merged
Merged
Conversation
@yarnpkg/core@4.9.2 declares got via a patch: protocol but does not ship the patch in its npm tarball, which forced us to vendor the file and copy it into both Docker stages. Resolving got to npm:11.8.2 in the root resolutions satisfies the descriptor without reading a patch file, so the vendored patch and its Docker COPY lines can go. Also keeps @yarnpkg/cli and @yarnpkg/core on the versions upstream expects, no pin skew. Co-authored-by: opencode-agent[bot] <219766164+opencode-agent[bot]@users.noreply.github.com>
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
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.
What
Removes the vendored
gotpatch file and instead resolvesgottonpm:11.8.2in the rootresolutions. Follow-up to #100.Why
The patch only existed because
@yarnpkg/core@4.9.2declaresgotwith apatch:protocol while failing to ship the patch inside its npm tarball. That forced two fragile things: vendoring a foreign patch file into.yarn/patches/, and remembering to copy it into every Docker stage that runsyarn install(the gap that broke the build in #100). Aresolutionsentry satisfies the same descriptor without Yarn ever reading a patch file.Changes
package.json: add"got": "npm:11.8.2"toresolutions.yarn/patches/got-npm-11.8.2-c1eb105458.patchDockerfile: drop the twoCOPY .yarn/patches/ .yarn/patches/lines from the build and run stagesyarn.lock: re-resolved,got@patch:descriptor redirected togot@npm:11.8.2Notes
@yarnpkg/cli@4.18.1and@yarnpkg/core@4.9.2on the exact versions upstream expects. The alternative (pinning@yarnpkg/coreto4.9.1) worked too but left@yarnpkg/cli's^4.9.2peer requirement unmet.patch:string inyarn.lockis upstream's declared range inside@yarnpkg/core's dependency listing; the resolution redirects it, which is why install succeeds with no.yarn/patches/directory present.Validation
mise run lintpasses (all workspaces)mise run testpasses: 9 tests passed, 1 skippedyarn installcompletes with.yarn/patches/absent--immutableinstall path in both stages