fix(cookbook): remove withResolvedCatalog from regenerate command#3723
fix(cookbook): remove withResolvedCatalog from regenerate command#3723fredericoo wants to merge 1 commit intomainfrom
Conversation
The regenerate command wrapped applyRecipe/generateRecipe/renderRecipe inside withResolvedCatalog(), which resolves workspace:* and catalog: protocols to concrete versions in package.json files before the callback runs. This broke patch application for recipes whose context lines include those protocol values (e.g. multipass, partytown) because the skeleton's package.json no longer matched what the patches expected. The regenerate command doesn't need resolved versions — patches need workspace:* intact for context matching, generateRecipe diffs against HEAD (which also has workspace:*), and renderRecipe just reads YAML. The existing git checkout/clean at the end of each loop iteration already handles skeleton restoration. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Oxygen deployed a preview of your
Learn more about Hydrogen's GitHub integration. |
|
@fredericoo Top hatting this PR and it does fix the The regenerate in this PR will now regenerate the package.json files and leave the
The current ordering is:
This fails because apply sees a resolved skeleton but patches have workspace:* context. Maybe if we move resolution to between apply and generate:
Now what should happen could be:
|
2 participants
WHY are these changes introduced?
withResolvedCatalog()resolvesworkspace:*andcatalog:protocols to concrete versions in all workspacepackage.jsonfiles. Theregeneratecommand wraps all three steps inside this helper, which meansapplyRecipe()sees resolved values (e.g."@shopify/hydrogen": "2026.4.0") instead of the original protocol strings. Patches whose context lines include"workspace:*"or"catalog:"fail to apply because the file no longer matches.Recipes whose patch context windows happen to avoid those lines (e.g. infinite-scroll, metaobjects) regenerate fine. Recipes like multipass and partytown fail.
How this went undetected
The bug was latent because the E2E validation tests use
--template <copy>, which applies patches to a copy of the skeleton that isn't modified by catalog resolution. So validation always passed. The issue only surfaces when runningregenerateagainst the in-tree skeleton (without--template), which is the normal developer workflow for refreshing recipes after skeleton changes.This was discovered while working on the Vite 8 migration (
fd-vite-8), where skeletonpackage.jsonchanges causedregenerateto fail on recipes like multipass and partytown. The workaround was callingapplyRecipe()directly and running generate/render separately — this PR eliminates the need for that workaround.WHAT is this pull request doing?
Removes the
withResolvedCatalog()wrapper from theregeneratecommand. The three inner steps don't need it:applyRecipe()needsworkspace:*intact so patch context matchesgenerateRecipe()diffs against HEAD, which also hasworkspace:*renderRecipe()reads YAML and generates markdownThe existing
git checkout/git cleanat the end of each loop iteration already handles skeleton restoration. Theapplyandvalidatecommands still usewithResolvedCatalog()— no dead code.HOW to test your changes?
cd cookbook npx ts-node src/index.ts regenerate --recipe multipass npx ts-node src/index.ts regenerate --recipe partytownBoth should succeed where they previously failed with patch application errors.
Checklist