Added patches README #24657
Added patches README #24657
Conversation
no issue - codifying our patches purpose and how to update patches as needed
WalkthroughAdds patches/README.md documenting patch-package usage. Describes an existing esm+3.2.25.patch that replaces esm with esm-wallaby to support Node.js 22.10.0–22.16.x for the Admin’s Ember.js build. Provides step-by-step workflow to update the patch (remove old patch, fetch/extract esm-wallaby, copy esm.js/loader.js into node_modules/esm, run npx patch-package esm, cleanup). Explains automatic application via postinstall after yarn install. Outlines procedures to create new patches and to update existing ones, including testing guidance. Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
patches/README.md (4)
7-12: Clarify/version-proof the Node.js compatibility statement.Hard-coding “Node.js 22.10.0 to 22.16.x” will go stale. Prefer linking to an upstream issue/changelog, or soften to “Node.js 22.x (tested on 22.10–22.16)” so we don’t need to constantly update docs.
15-22: Make the update script safer and reproducible (pin version, handle missing files).
- Use rm -f to avoid errors if the patch doesn’t exist.
- Pin esm-wallaby version for reproducibility (avoid pulling a moving latest).
- Ensure node_modules/esm exists before copying; nudge to run yarn install first.
- Fail fast on errors.
Apply this diff to replace the script:
-```bash -rm patches/esm+3.2.25.patch -dest=esm-wallaby && mkdir -p "$dest" && curl -sL "$(npm view esm-wallaby dist.tarball)" | tar -xz -C "$dest" --strip-components=1 -cp "esm-wallaby/esm.js" "node_modules/esm/esm.js" -cp "esm-wallaby/esm/loader.js" "node_modules/esm/esm/loader.js" -npx patch-package esm -rm -rf esm-wallaby -``` +```bash +set -euo pipefail + +# Ensure dependencies (including esm) are installed +test -d node_modules/esm || { echo "node_modules/esm not found. Run: yarn install"; exit 1; } + +# Remove old patch if present +rm -f patches/esm+3.2.25.patch + +# Pin esm-wallaby version for reproducibility (update as needed) +WALLABY_VER="${WALLABY_VER:-3.2.25}" +dest="esm-wallaby-${WALLABY_VER}" +mkdir -p "$dest" +curl -sL "$(npm view "esm-wallaby@${WALLABY_VER}" dist.tarball)" | tar -xz -C "$dest" --strip-components=1 + +# Copy files into esm package +install -m 0644 "${dest}/esm.js" "node_modules/esm/esm.js" +install -m 0644 "${dest}/esm/loader.js" "node_modules/esm/esm/loader.js" + +# Generate patch +npx patch-package esm + +# Cleanup +rm -rf "$dest" +```
34-45: Add a note to validate application and minimize diffs.
- After generating a patch, run yarn install once to ensure the patch applies cleanly via postinstall.
- Keep patch scope minimal (avoid committing build artifacts or unrelated changes within node_modules).
46-57: Call out filename/version changes and test across Node versions.
- The generated patch filename will change with the dependency version (e.g., esm+X.Y.Z.patch); commit the new file and remove the old.
- Explicitly test on the Node.js versions we support (including 22.x) to ensure the patch still resolves the original issue.
| Patches are automatically applied after `yarn install` runs via the `postinstall` script defined in `package.json`: | ||
|
|
||
| ```json | ||
| "postinstall": "patch-package" | ||
| ``` | ||
|
|
||
| This ensures that any modified dependencies are consistently patched across all environments (development, CI, production). | ||
|
|
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Ensure patch-package runs in all environments that install dependencies.
If patches must apply in production builds/containers, patch-package should be available when postinstall runs. Verify:
- package.json has "postinstall": "patch-package"
- patch-package is installed where postinstall can find it (often as a non-dev dependency if production installs omit devDependencies)
Run the script to confirm:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Checking postinstall hook..."
fd -t f package.json -d 2 | while read -r f; do
echo "File: $f"
jq -r '.scripts.postinstall // empty' "$f" | sed 's/^/ postinstall: /'
done
echo
echo "Checking where patch-package is declared..."
fd -t f package.json -d 2 | while read -r f; do
if jq -e '.dependencies["patch-package"]' "$f" >/dev/null; then
echo "patch-package in dependencies of $f"
elif jq -e '.devDependencies["patch-package"]' "$f" >/dev/null; then
echo "patch-package in devDependencies of $f"
fi
doneLength of output: 955
Ensure patch-package is available in all install environments
Patching is wired up via the postinstall hook, but in production builds where devDependencies are omitted, patch-package won’t be installed and your patches won’t apply. Please update:
• package.json (root)
– Move patch-package from devDependencies into dependencies so it’s present on production installs.
Example diff:
"devDependencies": {
- "patch-package": "^6.5.1",
+ // remove patch-package from here
},
// …
"dependencies": {
+ "patch-package": "^6.5.1",
// other runtime deps
}• e2e/package.json (if e2e runs its own yarn install)
– Add the same postinstall script and ensure patch-package is installed if you need patches applied in that context.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In patches/README.md around lines 26 to 33, the docs note patches run in
postinstall but don’t address that patch-package may be absent in production
installs; update the project manifests so patch-package is always present where
needed: move patch-package from root package.json devDependencies into
dependencies (so it’s installed in production builds), and if e2e runs its own
install, add the same postinstall script and add patch-package to
e2e/package.json dependencies (or ensure it’s installed in that install
environment) so patches are applied consistently.
no issue