docs(frontend): correct the engine-strict guard — it blocks npm ci too - #493

Merged
AndresL230 merged 1 commit into
mainfrom
fix/npm-engine-strict-docs
Jul 31, 2026
Merged

docs(frontend): correct the engine-strict guard — it blocks npm ci too#493
AndresL230 merged 1 commit into
mainfrom
fix/npm-engine-strict-docs

Conversation

@AndresL230

@AndresL230AndresL230 commented Jul 31, 2026

Copy link
Copy Markdown
Collaborator

frontend/.npmrc told contributors that engine-strict=true was a write-path-only guard, because "npm ci ignores engine-strict in npm >=7". That is false for modern npm.

Probed against a minimal package carrying the same >=10.9.0 <11 pin, on npm 12.0.1 / node v26.4.0:

commandengine-strictexit
npm citrue1 — EBADENGINE
npm installtrue1 — EBADENGINE
npm_config_engine_strict=false npm cibypassed0

It also explains a detail the old story never fit: the #113 frontend audit (2026-07-03, npm 11.6.2) had to run npm_config_engine_strict=false npm **ci**. If the guard were write-path-only, the bypass would not have been needed there at all. That session lost time to an empty node_modules — the failure is quiet, so npm run lint / npm run typecheck stop being a real gate instead of erroring.

Changes

  • frontend/.npmrc — replace the false mechanism block with what engine-strict actually does (both paths), the probe result and date, and the two real unblocks.
  • frontend/README.md — new "If your npm is 11 or newer" section under Run, so a contributor hits the answer before the empty node_modules.

Both keep the never-commit-an-off-pin-lockfile rule prominent — an off-pin lockfile is what breaks the Cloudflare Workers deploy, and the whole reason the pin exists.

.github/workflows/ci.yml's comment (":84 — .npmrc engine-strict=true enforces it during npm ci") was already correct and is unchanged.

Comments and docs only — no code, no lockfile, no dependency changes.

Follow-up

The live Canopy doc sapling-frontend-local-dev carries the same false claim; a corrected v2 is staged and needs promotion.

🤖 Generated with Claude Code

@AndresL230@claude
docs(frontend): correct the engine-strict guard — it blocks npm ci too
18b34c2
`frontend/.npmrc` claimed engine-strict was a write-path-only guard
because "`npm ci` ignores engine-strict in npm >=7". That is false for
modern npm. Probed against a minimal package carrying this exact
`>=10.9.0 <11` pin, on npm 12.0.1 / node v26.4.0:
npm ci -> exit 1, EBADENGINE
npm install -> exit 1, EBADENGINE
npm_config_engine_strict=false npm ci -> exit 0
It also matches the field evidence: the #113 frontend audit (2026-07-03,
npm 11.6.2) had to run `npm_config_engine_strict=false npm ci` — the
bypass was needed on the READ path, which the write-path-only story
never explained. That session lost time to an empty node_modules and a
silently disabled lint gate, because the failure is quiet: lint and
typecheck stop being a real gate instead of erroring.
- .npmrc: replace the false mechanism block with what engine-strict
actually does, the probe result, and the two real unblocks.
- README.md: new "If your npm is 11 or newer" section so contributors
hit the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — that is
what breaks the Cloudflare Workers deploy and the whole reason for the
pin. `.github/workflows/ci.yml`'s comment was already correct and is
unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@supabase

supabaseBot commented Jul 31, 2026

Copy link
Copy Markdown

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

@cloudflare-workers-and-pages

cloudflare-workers-and-pagesBot commented Jul 31, 2026

Copy link
Copy Markdown

Deploying with Cloudflare Workers Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

StatusNameLatest CommitPreview URLUpdated (UTC)
✅ Deployment successful!
View logs		frontend-staging18b34c2Commit Preview URL

Branch Preview URL		Jul 31 2026, 06:57 AM

@AndresL230

AndresL230 commented Jul 31, 2026

Copy link
Copy Markdown
CollaboratorAuthor

Verified independently before merging:

  • frontend/package.json does pin "npm": ">=10.9.0 <11".
  • This machine runs npm 12.0.1 — out of range, same class as the probe environment.
  • .github/workflows/ci.yml:84 already said ".npmrc engine-strict=true enforces it during npm ci", and :92 pins npm@10.9.2 with --engine-strict=false before installing. So the old .npmrc comment contradicted the repo's own CI config — the correction resolves a real internal inconsistency, not just a doc nit.

CI green across all lanes including the Workers build. Comments and docs only — no code, no lockfile, no dependency changes. Merging.

@AndresL230
AndresL230 merged commit d10c5e0 into mainJul 31, 2026
6 checks passed
@AndresL230
AndresL230 deleted the fix/npm-engine-strict-docs branch July 31, 2026 07:00
@coderabbitai

coderabbitaiBot commented Jul 31, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:39 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 1ad441b1-5cfc-4c82-9f5d-8a7ea982aeae

📥 Commits

Reviewing files that changed from the base of the PR and between 9c2f1a1 and 18b34c2.

📒 Files selected for processing (2)
  • frontend/.npmrc
  • frontend/README.md

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@AndresL230
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
docs(frontend): correct the engine-strict guard — it blocks npm ci too - #493
Merged
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Jul 31, 2026
Merged
docs(frontend): correct the engine-strict guard — it blocks npm ci too#493
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Conversation
@AndresL230
@AndresL230AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

Collaborator
frontend/.npmrc told contributors that engine-strict=true was a write-path-only guard, because "npm ci ignores engine-strict in npm >=7". That is false for modern npm.
Probed against a minimal package carrying the same >=10.9.0 <11 pin, on npm 12.0.1 / node v26.4.0:
commandengine-strictexit
npm citrue1 — EBADENGINE
npm installtrue1 — EBADENGINE
npm_config_engine_strict=false npm cibypassed0
It also explains a detail the old story never fit: the #113 frontend audit (2026-07-03, npm 11.6.2) had to run npm_config_engine_strict=false npm **ci**. If the guard were write-path-only, the bypass would not have been needed there at all. That session lost time to an empty node_modules — the failure is quiet, so npm run lint / npm run typecheck stop being a real gate instead of erroring.
Changes
  • frontend/.npmrc — replace the false mechanism block with what engine-strict actually does (both paths), the probe result and date, and the two real unblocks.
  • frontend/README.md — new "If your npm is 11 or newer" section under Run, so a contributor hits the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — an off-pin lockfile is what breaks the Cloudflare Workers deploy, and the whole reason the pin exists.
.github/workflows/ci.yml's comment (":84 — .npmrc engine-strict=true enforces it during npm ci") was already correct and is unchanged.
Comments and docs only — no code, no lockfile, no dependency changes.
Follow-up
The live Canopy doc sapling-frontend-local-dev carries the same false claim; a corrected v2 is staged and needs promotion.
🤖 Generated with Claude Code
@AndresL230@claude
docs(frontend): correct the engine-strict guard — it blocks npm ci too
18b34c2
`frontend/.npmrc` claimed engine-strict was a write-path-only guard
because "`npm ci` ignores engine-strict in npm >=7". That is false for
modern npm. Probed against a minimal package carrying this exact
`>=10.9.0 <11` pin, on npm 12.0.1 / node v26.4.0:
npm ci -> exit 1, EBADENGINE
npm install -> exit 1, EBADENGINE
npm_config_engine_strict=false npm ci -> exit 0
It also matches the field evidence: the #113 frontend audit (2026-07-03,
npm 11.6.2) had to run `npm_config_engine_strict=false npm ci` — the
bypass was needed on the READ path, which the write-path-only story
never explained. That session lost time to an empty node_modules and a
silently disabled lint gate, because the failure is quiet: lint and
typecheck stop being a real gate instead of erroring.
- .npmrc: replace the false mechanism block with what engine-strict
actually does, the probe result, and the two real unblocks.
- README.md: new "If your npm is 11 or newer" section so contributors
hit the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — that is
what breaks the Cloudflare Workers deploy and the whole reason for the
pin. `.github/workflows/ci.yml`'s comment was already correct and is
unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@supabase
supabaseBot
commented
Jul 31, 2026

Copy link


Copy Markdown

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.
Preview Branches by Supabase.

Learn more about Supabase Branching ↗︎.
@cloudflare-workers-and-pages
cloudflare-workers-and-pagesBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Deploying with Cloudflare Workers Cloudflare Workers
The latest updates on your project. Learn more about integrating Git with Workers.
StatusNameLatest CommitPreview URLUpdated (UTC)
✅ Deployment successful! 
View logs		frontend-staging18b34c2Commit Preview URL

Branch Preview URL		Jul 31 2026, 06:57 AM
@AndresL230
AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

CollaboratorAuthor
Verified independently before merging:
  • frontend/package.json does pin "npm": ">=10.9.0 <11".
  • This machine runs npm 12.0.1 — out of range, same class as the probe environment.
  • .github/workflows/ci.yml:84 already said ".npmrc engine-strict=true enforces it during npm ci", and :92 pins npm@10.9.2 with --engine-strict=false before installing. So the old .npmrc comment contradicted the repo's own CI config — the correction resolves a real internal inconsistency, not just a doc nit.
CI green across all lanes including the Workers build. Comments and docs only — no code, no lockfile, no dependency changes. Merging.
@AndresL230
AndresL230
merged commit d10c5e0
into
mainJul 31, 2026

6 checks passed

@AndresL230
AndresL230
deleted the

fix/npm-engine-strict-docs

branch
July 31, 2026 07:00
@coderabbitai
coderabbitaiBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Warning
Review limit reached
@AndresL230, you've reached your PR review limit, so we couldn't start this review.
Next review available in:39 minutes
Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.

You're only billed for reviews past your plan's rate limits ($0.25/file).
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.
For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.
Please refer docs for additional details.
Review details
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 1ad441b1-5cfc-4c82-9f5d-8a7ea982aeae
📥 Commits
Reviewing files that changed from the base of the PR and between 9c2f1a1 and 18b34c2.
📒 Files selected for processing (2)
  • frontend/.npmrc
  • frontend/README.md
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.
❤️ Share
Comment @coderabbitai help to get the list of available commands.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@AndresL230

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
docs(frontend): correct the engine-strict guard — it blocks npm ci too - #493
Merged
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Jul 31, 2026
Merged
docs(frontend): correct the engine-strict guard — it blocks npm ci too#493
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Conversation
@AndresL230
@AndresL230AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

Collaborator
frontend/.npmrc told contributors that engine-strict=true was a write-path-only guard, because "npm ci ignores engine-strict in npm >=7". That is false for modern npm.
Probed against a minimal package carrying the same >=10.9.0 <11 pin, on npm 12.0.1 / node v26.4.0:
commandengine-strictexit
npm citrue1 — EBADENGINE
npm installtrue1 — EBADENGINE
npm_config_engine_strict=false npm cibypassed0
It also explains a detail the old story never fit: the #113 frontend audit (2026-07-03, npm 11.6.2) had to run npm_config_engine_strict=false npm **ci**. If the guard were write-path-only, the bypass would not have been needed there at all. That session lost time to an empty node_modules — the failure is quiet, so npm run lint / npm run typecheck stop being a real gate instead of erroring.
Changes
  • frontend/.npmrc — replace the false mechanism block with what engine-strict actually does (both paths), the probe result and date, and the two real unblocks.
  • frontend/README.md — new "If your npm is 11 or newer" section under Run, so a contributor hits the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — an off-pin lockfile is what breaks the Cloudflare Workers deploy, and the whole reason the pin exists.
.github/workflows/ci.yml's comment (":84 — .npmrc engine-strict=true enforces it during npm ci") was already correct and is unchanged.
Comments and docs only — no code, no lockfile, no dependency changes.
Follow-up
The live Canopy doc sapling-frontend-local-dev carries the same false claim; a corrected v2 is staged and needs promotion.
🤖 Generated with Claude Code
@AndresL230@claude
docs(frontend): correct the engine-strict guard — it blocks npm ci too
18b34c2
`frontend/.npmrc` claimed engine-strict was a write-path-only guard
because "`npm ci` ignores engine-strict in npm >=7". That is false for
modern npm. Probed against a minimal package carrying this exact
`>=10.9.0 <11` pin, on npm 12.0.1 / node v26.4.0:
npm ci -> exit 1, EBADENGINE
npm install -> exit 1, EBADENGINE
npm_config_engine_strict=false npm ci -> exit 0
It also matches the field evidence: the #113 frontend audit (2026-07-03,
npm 11.6.2) had to run `npm_config_engine_strict=false npm ci` — the
bypass was needed on the READ path, which the write-path-only story
never explained. That session lost time to an empty node_modules and a
silently disabled lint gate, because the failure is quiet: lint and
typecheck stop being a real gate instead of erroring.
- .npmrc: replace the false mechanism block with what engine-strict
actually does, the probe result, and the two real unblocks.
- README.md: new "If your npm is 11 or newer" section so contributors
hit the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — that is
what breaks the Cloudflare Workers deploy and the whole reason for the
pin. `.github/workflows/ci.yml`'s comment was already correct and is
unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@supabase
supabaseBot
commented
Jul 31, 2026

Copy link


Copy Markdown

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.
Preview Branches by Supabase.

Learn more about Supabase Branching ↗︎.
@cloudflare-workers-and-pages
cloudflare-workers-and-pagesBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Deploying with Cloudflare Workers Cloudflare Workers
The latest updates on your project. Learn more about integrating Git with Workers.
StatusNameLatest CommitPreview URLUpdated (UTC)
✅ Deployment successful! 
View logs		frontend-staging18b34c2Commit Preview URL

Branch Preview URL		Jul 31 2026, 06:57 AM
@AndresL230
AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

CollaboratorAuthor
Verified independently before merging:
  • frontend/package.json does pin "npm": ">=10.9.0 <11".
  • This machine runs npm 12.0.1 — out of range, same class as the probe environment.
  • .github/workflows/ci.yml:84 already said ".npmrc engine-strict=true enforces it during npm ci", and :92 pins npm@10.9.2 with --engine-strict=false before installing. So the old .npmrc comment contradicted the repo's own CI config — the correction resolves a real internal inconsistency, not just a doc nit.
CI green across all lanes including the Workers build. Comments and docs only — no code, no lockfile, no dependency changes. Merging.
@AndresL230
AndresL230
merged commit d10c5e0
into
mainJul 31, 2026

6 checks passed

@AndresL230
AndresL230
deleted the

fix/npm-engine-strict-docs

branch
July 31, 2026 07:00
@coderabbitai
coderabbitaiBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Warning
Review limit reached
@AndresL230, you've reached your PR review limit, so we couldn't start this review.
Next review available in:39 minutes
Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.

You're only billed for reviews past your plan's rate limits ($0.25/file).
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.
For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.
Please refer docs for additional details.
Review details
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 1ad441b1-5cfc-4c82-9f5d-8a7ea982aeae
📥 Commits
Reviewing files that changed from the base of the PR and between 9c2f1a1 and 18b34c2.
📒 Files selected for processing (2)
  • frontend/.npmrc
  • frontend/README.md
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.
❤️ Share
Comment @coderabbitai help to get the list of available commands.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@AndresL230

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
docs(frontend): correct the engine-strict guard — it blocks npm ci too - #493
Merged
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Jul 31, 2026
Merged
docs(frontend): correct the engine-strict guard — it blocks npm ci too#493
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Conversation
@AndresL230
@AndresL230AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

Collaborator
frontend/.npmrc told contributors that engine-strict=true was a write-path-only guard, because "npm ci ignores engine-strict in npm >=7". That is false for modern npm.
Probed against a minimal package carrying the same >=10.9.0 <11 pin, on npm 12.0.1 / node v26.4.0:
commandengine-strictexit
npm citrue1 — EBADENGINE
npm installtrue1 — EBADENGINE
npm_config_engine_strict=false npm cibypassed0
It also explains a detail the old story never fit: the #113 frontend audit (2026-07-03, npm 11.6.2) had to run npm_config_engine_strict=false npm **ci**. If the guard were write-path-only, the bypass would not have been needed there at all. That session lost time to an empty node_modules — the failure is quiet, so npm run lint / npm run typecheck stop being a real gate instead of erroring.
Changes
  • frontend/.npmrc — replace the false mechanism block with what engine-strict actually does (both paths), the probe result and date, and the two real unblocks.
  • frontend/README.md — new "If your npm is 11 or newer" section under Run, so a contributor hits the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — an off-pin lockfile is what breaks the Cloudflare Workers deploy, and the whole reason the pin exists.
.github/workflows/ci.yml's comment (":84 — .npmrc engine-strict=true enforces it during npm ci") was already correct and is unchanged.
Comments and docs only — no code, no lockfile, no dependency changes.
Follow-up
The live Canopy doc sapling-frontend-local-dev carries the same false claim; a corrected v2 is staged and needs promotion.
🤖 Generated with Claude Code
@AndresL230@claude
docs(frontend): correct the engine-strict guard — it blocks npm ci too
18b34c2
`frontend/.npmrc` claimed engine-strict was a write-path-only guard
because "`npm ci` ignores engine-strict in npm >=7". That is false for
modern npm. Probed against a minimal package carrying this exact
`>=10.9.0 <11` pin, on npm 12.0.1 / node v26.4.0:
npm ci -> exit 1, EBADENGINE
npm install -> exit 1, EBADENGINE
npm_config_engine_strict=false npm ci -> exit 0
It also matches the field evidence: the #113 frontend audit (2026-07-03,
npm 11.6.2) had to run `npm_config_engine_strict=false npm ci` — the
bypass was needed on the READ path, which the write-path-only story
never explained. That session lost time to an empty node_modules and a
silently disabled lint gate, because the failure is quiet: lint and
typecheck stop being a real gate instead of erroring.
- .npmrc: replace the false mechanism block with what engine-strict
actually does, the probe result, and the two real unblocks.
- README.md: new "If your npm is 11 or newer" section so contributors
hit the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — that is
what breaks the Cloudflare Workers deploy and the whole reason for the
pin. `.github/workflows/ci.yml`'s comment was already correct and is
unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@supabase
supabaseBot
commented
Jul 31, 2026

Copy link


Copy Markdown

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.
Preview Branches by Supabase.

Learn more about Supabase Branching ↗︎.
@cloudflare-workers-and-pages
cloudflare-workers-and-pagesBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Deploying with Cloudflare Workers Cloudflare Workers
The latest updates on your project. Learn more about integrating Git with Workers.
StatusNameLatest CommitPreview URLUpdated (UTC)
✅ Deployment successful! 
View logs		frontend-staging18b34c2Commit Preview URL

Branch Preview URL		Jul 31 2026, 06:57 AM
@AndresL230
AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

CollaboratorAuthor
Verified independently before merging:
  • frontend/package.json does pin "npm": ">=10.9.0 <11".
  • This machine runs npm 12.0.1 — out of range, same class as the probe environment.
  • .github/workflows/ci.yml:84 already said ".npmrc engine-strict=true enforces it during npm ci", and :92 pins npm@10.9.2 with --engine-strict=false before installing. So the old .npmrc comment contradicted the repo's own CI config — the correction resolves a real internal inconsistency, not just a doc nit.
CI green across all lanes including the Workers build. Comments and docs only — no code, no lockfile, no dependency changes. Merging.
@AndresL230
AndresL230
merged commit d10c5e0
into
mainJul 31, 2026

6 checks passed

@AndresL230
AndresL230
deleted the

fix/npm-engine-strict-docs

branch
July 31, 2026 07:00
@coderabbitai
coderabbitaiBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Warning
Review limit reached
@AndresL230, you've reached your PR review limit, so we couldn't start this review.
Next review available in:39 minutes
Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.

You're only billed for reviews past your plan's rate limits ($0.25/file).
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.
For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.
Please refer docs for additional details.
Review details
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 1ad441b1-5cfc-4c82-9f5d-8a7ea982aeae
📥 Commits
Reviewing files that changed from the base of the PR and between 9c2f1a1 and 18b34c2.
📒 Files selected for processing (2)
  • frontend/.npmrc
  • frontend/README.md
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.
❤️ Share
Comment @coderabbitai help to get the list of available commands.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@AndresL230

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
docs(frontend): correct the engine-strict guard — it blocks npm ci too - #493
Merged
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Jul 31, 2026
Merged
docs(frontend): correct the engine-strict guard — it blocks npm ci too#493
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Conversation
@AndresL230
@AndresL230AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

Collaborator
frontend/.npmrc told contributors that engine-strict=true was a write-path-only guard, because "npm ci ignores engine-strict in npm >=7". That is false for modern npm.
Probed against a minimal package carrying the same >=10.9.0 <11 pin, on npm 12.0.1 / node v26.4.0:
commandengine-strictexit
npm citrue1 — EBADENGINE
npm installtrue1 — EBADENGINE
npm_config_engine_strict=false npm cibypassed0
It also explains a detail the old story never fit: the #113 frontend audit (2026-07-03, npm 11.6.2) had to run npm_config_engine_strict=false npm **ci**. If the guard were write-path-only, the bypass would not have been needed there at all. That session lost time to an empty node_modules — the failure is quiet, so npm run lint / npm run typecheck stop being a real gate instead of erroring.
Changes
  • frontend/.npmrc — replace the false mechanism block with what engine-strict actually does (both paths), the probe result and date, and the two real unblocks.
  • frontend/README.md — new "If your npm is 11 or newer" section under Run, so a contributor hits the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — an off-pin lockfile is what breaks the Cloudflare Workers deploy, and the whole reason the pin exists.
.github/workflows/ci.yml's comment (":84 — .npmrc engine-strict=true enforces it during npm ci") was already correct and is unchanged.
Comments and docs only — no code, no lockfile, no dependency changes.
Follow-up
The live Canopy doc sapling-frontend-local-dev carries the same false claim; a corrected v2 is staged and needs promotion.
🤖 Generated with Claude Code
@AndresL230@claude
docs(frontend): correct the engine-strict guard — it blocks npm ci too
18b34c2
`frontend/.npmrc` claimed engine-strict was a write-path-only guard
because "`npm ci` ignores engine-strict in npm >=7". That is false for
modern npm. Probed against a minimal package carrying this exact
`>=10.9.0 <11` pin, on npm 12.0.1 / node v26.4.0:
npm ci -> exit 1, EBADENGINE
npm install -> exit 1, EBADENGINE
npm_config_engine_strict=false npm ci -> exit 0
It also matches the field evidence: the #113 frontend audit (2026-07-03,
npm 11.6.2) had to run `npm_config_engine_strict=false npm ci` — the
bypass was needed on the READ path, which the write-path-only story
never explained. That session lost time to an empty node_modules and a
silently disabled lint gate, because the failure is quiet: lint and
typecheck stop being a real gate instead of erroring.
- .npmrc: replace the false mechanism block with what engine-strict
actually does, the probe result, and the two real unblocks.
- README.md: new "If your npm is 11 or newer" section so contributors
hit the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — that is
what breaks the Cloudflare Workers deploy and the whole reason for the
pin. `.github/workflows/ci.yml`'s comment was already correct and is
unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@supabase
supabaseBot
commented
Jul 31, 2026

Copy link


Copy Markdown

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.
Preview Branches by Supabase.

Learn more about Supabase Branching ↗︎.
@cloudflare-workers-and-pages
cloudflare-workers-and-pagesBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Deploying with Cloudflare Workers Cloudflare Workers
The latest updates on your project. Learn more about integrating Git with Workers.
StatusNameLatest CommitPreview URLUpdated (UTC)
✅ Deployment successful! 
View logs		frontend-staging18b34c2Commit Preview URL

Branch Preview URL		Jul 31 2026, 06:57 AM
@AndresL230
AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

CollaboratorAuthor
Verified independently before merging:
  • frontend/package.json does pin "npm": ">=10.9.0 <11".
  • This machine runs npm 12.0.1 — out of range, same class as the probe environment.
  • .github/workflows/ci.yml:84 already said ".npmrc engine-strict=true enforces it during npm ci", and :92 pins npm@10.9.2 with --engine-strict=false before installing. So the old .npmrc comment contradicted the repo's own CI config — the correction resolves a real internal inconsistency, not just a doc nit.
CI green across all lanes including the Workers build. Comments and docs only — no code, no lockfile, no dependency changes. Merging.
@AndresL230
AndresL230
merged commit d10c5e0
into
mainJul 31, 2026

6 checks passed

@AndresL230
AndresL230
deleted the

fix/npm-engine-strict-docs

branch
July 31, 2026 07:00
@coderabbitai
coderabbitaiBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Warning
Review limit reached
@AndresL230, you've reached your PR review limit, so we couldn't start this review.
Next review available in:39 minutes
Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.

You're only billed for reviews past your plan's rate limits ($0.25/file).
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.
For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.
Please refer docs for additional details.
Review details
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 1ad441b1-5cfc-4c82-9f5d-8a7ea982aeae
📥 Commits
Reviewing files that changed from the base of the PR and between 9c2f1a1 and 18b34c2.
📒 Files selected for processing (2)
  • frontend/.npmrc
  • frontend/README.md
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.
❤️ Share
Comment @coderabbitai help to get the list of available commands.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@AndresL230

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
docs(frontend): correct the engine-strict guard — it blocks npm ci too - #493
Merged
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Jul 31, 2026
Merged
docs(frontend): correct the engine-strict guard — it blocks npm ci too#493
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Conversation
@AndresL230
@AndresL230AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

Collaborator
frontend/.npmrc told contributors that engine-strict=true was a write-path-only guard, because "npm ci ignores engine-strict in npm >=7". That is false for modern npm.
Probed against a minimal package carrying the same >=10.9.0 <11 pin, on npm 12.0.1 / node v26.4.0:
commandengine-strictexit
npm citrue1 — EBADENGINE
npm installtrue1 — EBADENGINE
npm_config_engine_strict=false npm cibypassed0
It also explains a detail the old story never fit: the #113 frontend audit (2026-07-03, npm 11.6.2) had to run npm_config_engine_strict=false npm **ci**. If the guard were write-path-only, the bypass would not have been needed there at all. That session lost time to an empty node_modules — the failure is quiet, so npm run lint / npm run typecheck stop being a real gate instead of erroring.
Changes
  • frontend/.npmrc — replace the false mechanism block with what engine-strict actually does (both paths), the probe result and date, and the two real unblocks.
  • frontend/README.md — new "If your npm is 11 or newer" section under Run, so a contributor hits the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — an off-pin lockfile is what breaks the Cloudflare Workers deploy, and the whole reason the pin exists.
.github/workflows/ci.yml's comment (":84 — .npmrc engine-strict=true enforces it during npm ci") was already correct and is unchanged.
Comments and docs only — no code, no lockfile, no dependency changes.
Follow-up
The live Canopy doc sapling-frontend-local-dev carries the same false claim; a corrected v2 is staged and needs promotion.
🤖 Generated with Claude Code
@AndresL230@claude
docs(frontend): correct the engine-strict guard — it blocks npm ci too
18b34c2
`frontend/.npmrc` claimed engine-strict was a write-path-only guard
because "`npm ci` ignores engine-strict in npm >=7". That is false for
modern npm. Probed against a minimal package carrying this exact
`>=10.9.0 <11` pin, on npm 12.0.1 / node v26.4.0:
npm ci -> exit 1, EBADENGINE
npm install -> exit 1, EBADENGINE
npm_config_engine_strict=false npm ci -> exit 0
It also matches the field evidence: the #113 frontend audit (2026-07-03,
npm 11.6.2) had to run `npm_config_engine_strict=false npm ci` — the
bypass was needed on the READ path, which the write-path-only story
never explained. That session lost time to an empty node_modules and a
silently disabled lint gate, because the failure is quiet: lint and
typecheck stop being a real gate instead of erroring.
- .npmrc: replace the false mechanism block with what engine-strict
actually does, the probe result, and the two real unblocks.
- README.md: new "If your npm is 11 or newer" section so contributors
hit the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — that is
what breaks the Cloudflare Workers deploy and the whole reason for the
pin. `.github/workflows/ci.yml`'s comment was already correct and is
unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@supabase
supabaseBot
commented
Jul 31, 2026

Copy link


Copy Markdown

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.
Preview Branches by Supabase.

Learn more about Supabase Branching ↗︎.
@cloudflare-workers-and-pages
cloudflare-workers-and-pagesBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Deploying with Cloudflare Workers Cloudflare Workers
The latest updates on your project. Learn more about integrating Git with Workers.
StatusNameLatest CommitPreview URLUpdated (UTC)
✅ Deployment successful! 
View logs		frontend-staging18b34c2Commit Preview URL

Branch Preview URL		Jul 31 2026, 06:57 AM
@AndresL230
AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

CollaboratorAuthor
Verified independently before merging:
  • frontend/package.json does pin "npm": ">=10.9.0 <11".
  • This machine runs npm 12.0.1 — out of range, same class as the probe environment.
  • .github/workflows/ci.yml:84 already said ".npmrc engine-strict=true enforces it during npm ci", and :92 pins npm@10.9.2 with --engine-strict=false before installing. So the old .npmrc comment contradicted the repo's own CI config — the correction resolves a real internal inconsistency, not just a doc nit.
CI green across all lanes including the Workers build. Comments and docs only — no code, no lockfile, no dependency changes. Merging.
@AndresL230
AndresL230
merged commit d10c5e0
into
mainJul 31, 2026

6 checks passed

@AndresL230
AndresL230
deleted the

fix/npm-engine-strict-docs

branch
July 31, 2026 07:00
@coderabbitai
coderabbitaiBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Warning
Review limit reached
@AndresL230, you've reached your PR review limit, so we couldn't start this review.
Next review available in:39 minutes
Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.

You're only billed for reviews past your plan's rate limits ($0.25/file).
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.
For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.
Please refer docs for additional details.
Review details
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 1ad441b1-5cfc-4c82-9f5d-8a7ea982aeae
📥 Commits
Reviewing files that changed from the base of the PR and between 9c2f1a1 and 18b34c2.
📒 Files selected for processing (2)
  • frontend/.npmrc
  • frontend/README.md
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.
❤️ Share
Comment @coderabbitai help to get the list of available commands.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@AndresL230

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
docs(frontend): correct the engine-strict guard — it blocks npm ci too - #493
Merged
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Jul 31, 2026
Merged
docs(frontend): correct the engine-strict guard — it blocks npm ci too#493
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Conversation
@AndresL230
@AndresL230AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

Collaborator
frontend/.npmrc told contributors that engine-strict=true was a write-path-only guard, because "npm ci ignores engine-strict in npm >=7". That is false for modern npm.
Probed against a minimal package carrying the same >=10.9.0 <11 pin, on npm 12.0.1 / node v26.4.0:
commandengine-strictexit
npm citrue1 — EBADENGINE
npm installtrue1 — EBADENGINE
npm_config_engine_strict=false npm cibypassed0
It also explains a detail the old story never fit: the #113 frontend audit (2026-07-03, npm 11.6.2) had to run npm_config_engine_strict=false npm **ci**. If the guard were write-path-only, the bypass would not have been needed there at all. That session lost time to an empty node_modules — the failure is quiet, so npm run lint / npm run typecheck stop being a real gate instead of erroring.
Changes
  • frontend/.npmrc — replace the false mechanism block with what engine-strict actually does (both paths), the probe result and date, and the two real unblocks.
  • frontend/README.md — new "If your npm is 11 or newer" section under Run, so a contributor hits the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — an off-pin lockfile is what breaks the Cloudflare Workers deploy, and the whole reason the pin exists.
.github/workflows/ci.yml's comment (":84 — .npmrc engine-strict=true enforces it during npm ci") was already correct and is unchanged.
Comments and docs only — no code, no lockfile, no dependency changes.
Follow-up
The live Canopy doc sapling-frontend-local-dev carries the same false claim; a corrected v2 is staged and needs promotion.
🤖 Generated with Claude Code
@AndresL230@claude
docs(frontend): correct the engine-strict guard — it blocks npm ci too
18b34c2
`frontend/.npmrc` claimed engine-strict was a write-path-only guard
because "`npm ci` ignores engine-strict in npm >=7". That is false for
modern npm. Probed against a minimal package carrying this exact
`>=10.9.0 <11` pin, on npm 12.0.1 / node v26.4.0:
npm ci -> exit 1, EBADENGINE
npm install -> exit 1, EBADENGINE
npm_config_engine_strict=false npm ci -> exit 0
It also matches the field evidence: the #113 frontend audit (2026-07-03,
npm 11.6.2) had to run `npm_config_engine_strict=false npm ci` — the
bypass was needed on the READ path, which the write-path-only story
never explained. That session lost time to an empty node_modules and a
silently disabled lint gate, because the failure is quiet: lint and
typecheck stop being a real gate instead of erroring.
- .npmrc: replace the false mechanism block with what engine-strict
actually does, the probe result, and the two real unblocks.
- README.md: new "If your npm is 11 or newer" section so contributors
hit the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — that is
what breaks the Cloudflare Workers deploy and the whole reason for the
pin. `.github/workflows/ci.yml`'s comment was already correct and is
unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@supabase
supabaseBot
commented
Jul 31, 2026

Copy link


Copy Markdown

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.
Preview Branches by Supabase.

Learn more about Supabase Branching ↗︎.
@cloudflare-workers-and-pages
cloudflare-workers-and-pagesBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Deploying with Cloudflare Workers Cloudflare Workers
The latest updates on your project. Learn more about integrating Git with Workers.
StatusNameLatest CommitPreview URLUpdated (UTC)
✅ Deployment successful! 
View logs		frontend-staging18b34c2Commit Preview URL

Branch Preview URL		Jul 31 2026, 06:57 AM
@AndresL230
AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

CollaboratorAuthor
Verified independently before merging:
  • frontend/package.json does pin "npm": ">=10.9.0 <11".
  • This machine runs npm 12.0.1 — out of range, same class as the probe environment.
  • .github/workflows/ci.yml:84 already said ".npmrc engine-strict=true enforces it during npm ci", and :92 pins npm@10.9.2 with --engine-strict=false before installing. So the old .npmrc comment contradicted the repo's own CI config — the correction resolves a real internal inconsistency, not just a doc nit.
CI green across all lanes including the Workers build. Comments and docs only — no code, no lockfile, no dependency changes. Merging.
@AndresL230
AndresL230
merged commit d10c5e0
into
mainJul 31, 2026

6 checks passed

@AndresL230
AndresL230
deleted the

fix/npm-engine-strict-docs

branch
July 31, 2026 07:00
@coderabbitai
coderabbitaiBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Warning
Review limit reached
@AndresL230, you've reached your PR review limit, so we couldn't start this review.
Next review available in:39 minutes
Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.

You're only billed for reviews past your plan's rate limits ($0.25/file).
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.
For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.
Please refer docs for additional details.
Review details
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 1ad441b1-5cfc-4c82-9f5d-8a7ea982aeae
📥 Commits
Reviewing files that changed from the base of the PR and between 9c2f1a1 and 18b34c2.
📒 Files selected for processing (2)
  • frontend/.npmrc
  • frontend/README.md
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.
❤️ Share
Comment @coderabbitai help to get the list of available commands.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@AndresL230

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
docs(frontend): correct the engine-strict guard — it blocks npm ci too - #493
Merged
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Jul 31, 2026
Merged
docs(frontend): correct the engine-strict guard — it blocks npm ci too#493
AndresL230 merged 1 commit into
mainfrom 
fix/npm-engine-strict-docs
Conversation
@AndresL230
@AndresL230AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

Collaborator
frontend/.npmrc told contributors that engine-strict=true was a write-path-only guard, because "npm ci ignores engine-strict in npm >=7". That is false for modern npm.
Probed against a minimal package carrying the same >=10.9.0 <11 pin, on npm 12.0.1 / node v26.4.0:
commandengine-strictexit
npm citrue1 — EBADENGINE
npm installtrue1 — EBADENGINE
npm_config_engine_strict=false npm cibypassed0
It also explains a detail the old story never fit: the #113 frontend audit (2026-07-03, npm 11.6.2) had to run npm_config_engine_strict=false npm **ci**. If the guard were write-path-only, the bypass would not have been needed there at all. That session lost time to an empty node_modules — the failure is quiet, so npm run lint / npm run typecheck stop being a real gate instead of erroring.
Changes
  • frontend/.npmrc — replace the false mechanism block with what engine-strict actually does (both paths), the probe result and date, and the two real unblocks.
  • frontend/README.md — new "If your npm is 11 or newer" section under Run, so a contributor hits the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — an off-pin lockfile is what breaks the Cloudflare Workers deploy, and the whole reason the pin exists.
.github/workflows/ci.yml's comment (":84 — .npmrc engine-strict=true enforces it during npm ci") was already correct and is unchanged.
Comments and docs only — no code, no lockfile, no dependency changes.
Follow-up
The live Canopy doc sapling-frontend-local-dev carries the same false claim; a corrected v2 is staged and needs promotion.
🤖 Generated with Claude Code
@AndresL230@claude
docs(frontend): correct the engine-strict guard — it blocks npm ci too
18b34c2
`frontend/.npmrc` claimed engine-strict was a write-path-only guard
because "`npm ci` ignores engine-strict in npm >=7". That is false for
modern npm. Probed against a minimal package carrying this exact
`>=10.9.0 <11` pin, on npm 12.0.1 / node v26.4.0:
npm ci -> exit 1, EBADENGINE
npm install -> exit 1, EBADENGINE
npm_config_engine_strict=false npm ci -> exit 0
It also matches the field evidence: the #113 frontend audit (2026-07-03,
npm 11.6.2) had to run `npm_config_engine_strict=false npm ci` — the
bypass was needed on the READ path, which the write-path-only story
never explained. That session lost time to an empty node_modules and a
silently disabled lint gate, because the failure is quiet: lint and
typecheck stop being a real gate instead of erroring.
- .npmrc: replace the false mechanism block with what engine-strict
actually does, the probe result, and the two real unblocks.
- README.md: new "If your npm is 11 or newer" section so contributors
hit the answer before the empty node_modules.
Both keep the never-commit-an-off-pin-lockfile rule prominent — that is
what breaks the Cloudflare Workers deploy and the whole reason for the
pin. `.github/workflows/ci.yml`'s comment was already correct and is
unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@supabase
supabaseBot
commented
Jul 31, 2026

Copy link


Copy Markdown

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.
Preview Branches by Supabase.

Learn more about Supabase Branching ↗︎.
@cloudflare-workers-and-pages
cloudflare-workers-and-pagesBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Deploying with Cloudflare Workers Cloudflare Workers
The latest updates on your project. Learn more about integrating Git with Workers.
StatusNameLatest CommitPreview URLUpdated (UTC)
✅ Deployment successful! 
View logs		frontend-staging18b34c2Commit Preview URL

Branch Preview URL		Jul 31 2026, 06:57 AM
@AndresL230
AndresL230
commented
Jul 31, 2026

Copy link


Copy Markdown

CollaboratorAuthor
Verified independently before merging:
  • frontend/package.json does pin "npm": ">=10.9.0 <11".
  • This machine runs npm 12.0.1 — out of range, same class as the probe environment.
  • .github/workflows/ci.yml:84 already said ".npmrc engine-strict=true enforces it during npm ci", and :92 pins npm@10.9.2 with --engine-strict=false before installing. So the old .npmrc comment contradicted the repo's own CI config — the correction resolves a real internal inconsistency, not just a doc nit.
CI green across all lanes including the Workers build. Comments and docs only — no code, no lockfile, no dependency changes. Merging.
@AndresL230
AndresL230
merged commit d10c5e0
into
mainJul 31, 2026

6 checks passed

@AndresL230
AndresL230
deleted the

fix/npm-engine-strict-docs

branch
July 31, 2026 07:00
@coderabbitai
coderabbitaiBot
commented
Jul 31, 2026

Copy link


Copy Markdown

Warning
Review limit reached
@AndresL230, you've reached your PR review limit, so we couldn't start this review.
Next review available in:39 minutes
Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.

You're only billed for reviews past your plan's rate limits ($0.25/file).
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.
For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.
Please refer docs for additional details.
Review details
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 1ad441b1-5cfc-4c82-9f5d-8a7ea982aeae
📥 Commits
Reviewing files that changed from the base of the PR and between 9c2f1a1 and 18b34c2.
📒 Files selected for processing (2)
  • frontend/.npmrc
  • frontend/README.md
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.
❤️ Share
Comment @coderabbitai help to get the list of available commands.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@AndresL230