Feature/netlify config#589
Conversation
❌ Deploy Preview for github-spy failed.
|
📝 WalkthroughWalkthroughThis PR updates deployment configuration for the project: it pins a new github_tracker submodule commit, configures Netlify build settings and publishes to the ChangesDeployment and Hosting Configuration
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 3❌ Failed checks (2 warnings, 1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
github_tracker (1)
1-223:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winSubmodule update is committed as text content instead of a gitlink pointer.
This file contains embedded commit metadata and a full patch body, which indicates the submodule update was recorded incorrectly. The parent repo should only store the submodule commit pointer (gitlink), not the submodule diff text. Please reset this to a real submodule reference update and remove the pasted patch content from
github_tracker.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@github_tracker` around lines 1 - 223, The file github_tracker contains a pasted submodule diff/commit metadata instead of a gitlink; remove the embedded patch text and replace it with a proper submodule pointer update. To fix: delete the pasted patch content from the github_tracker file, add the submodule correctly (or run git submodule update --init --recursive to fetch the submodule) and update the parent repo to record the submodule commit SHA as a gitlink (so the index stores mode 160000 with the submodule commit), then commit that change; ensure the resulting commit only updates the submodule pointer and does not include the patch body.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@netlify.toml`:
- Line 2: The Netlify build command uses a non-deterministic install ("npm
install && npm run build"); generate and commit a package-lock.json to the repo,
then update the command in netlify.toml to use "npm ci && npm run build" so
installs are reproducible; specifically, replace the existing command string
value in netlify.toml with the npm ci variant after committing
package-lock.json.
- Line 4: The Netlify build env pins NODE_VERSION to an EOL release; update the
environment = { NODE_VERSION = "18" } entry to use the current Active LTS by
setting NODE_VERSION to "24" (or "22" only if explicit compatibility requires a
Maintenance LTS fallback), and ensure any CI/build docs that reference
NODE_VERSION are aligned with the change so builds use Node 24 by default.
---
Outside diff comments:
In `@github_tracker`:
- Around line 1-223: The file github_tracker contains a pasted submodule
diff/commit metadata instead of a gitlink; remove the embedded patch text and
replace it with a proper submodule pointer update. To fix: delete the pasted
patch content from the github_tracker file, add the submodule correctly (or run
git submodule update --init --recursive to fetch the submodule) and update the
parent repo to record the submodule commit SHA as a gitlink (so the index stores
mode 160000 with the submodule commit), then commit that change; ensure the
resulting commit only updates the submodule pointer and does not include the
patch body.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 929c8383-49c1-40c7-ac9c-88b344e8f2aa
📒 Files selected for processing (4)
github_trackernetlify.tomlpublic/_headerspublic/_redirects
| @@ -0,0 +1,17 @@ | |||
| [build] | |||
| command = "npm install && npm run build" | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify lockfile exists before switching install strategy
fd -HI '^package-lock\.json$' .Repository: GitMetricsLab/github_tracker
Length of output: 54
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== netlify.toml =="
if [ -f netlify.toml ]; then
nl -ba netlify.toml | sed -n '1,20p'
else
echo "netlify.toml not found at repo root"
fi
echo
echo "== package-lock.json matches =="
fd -HI '^package-lock\.json$' .Repository: GitMetricsLab/github_tracker
Length of output: 152
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== netlify.toml location(s) =="
fd -HI 'netlify\.toml$' .
echo
echo "== netlify.toml content (if present) =="
NETLIFY_FILES=$(fd -HI 'netlify\.toml$' . || true)
if [ -z "$NETLIFY_FILES" ]; then
echo "No netlify.toml found."
else
# Print with line numbers using awk (avoid nl)
echo "$NETLIFY_FILES" | head -n 5 | while IFS= read -r f; do
echo "--- $f ---"
awk '{printf "%d:%s\n", NR, $0}' "$f" | sed -n '1,60p'
done
fi
echo
echo "== package-lock.json matches =="
fd -HI '^package-lock\.json$' .Repository: GitMetricsLab/github_tracker
Length of output: 680
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== lockfiles (package-lock.json) =="
fd -HI 'package-lock\.json$' .
echo
echo "== other lockfiles =="
fd -HI 'package-lock\.(json|yaml|yml)$' . || true
fd -HI 'yarn\.lock$' .
fd -HI 'pnpm-lock\.yaml$' .Repository: GitMetricsLab/github_tracker
Length of output: 131
Make Netlify dependency installs deterministic (commit package-lock.json, then use npm ci).
netlify.toml uses npm install && npm run build, but there is no package-lock.json in the repo—so switching to npm ci would fail. Add/commit package-lock.json, then change the build command to npm ci && npm run build for reproducible installs.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@netlify.toml` at line 2, The Netlify build command uses a non-deterministic
install ("npm install && npm run build"); generate and commit a
package-lock.json to the repo, then update the command in netlify.toml to use
"npm ci && npm run build" so installs are reproducible; specifically, replace
the existing command string value in netlify.toml with the npm ci variant after
committing package-lock.json.
| [build] | ||
| command = "npm install && npm run build" | ||
| publish = "dist" | ||
| environment = { NODE_VERSION = "18" } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
As of May 2026, what is the Node.js release schedule/status for Node 18, Node 20, and Node 22, and which versions are in active support or maintenance?
💡 Result:
As of May 28, 2026, the status of the requested Node.js versions is as follows: Node.js 18: This version has reached its End-of-Life (EOL) [1][2]. It transitioned to maintenance mode on October 18, 2023, and officially reached its EOL date on April 30, 2025 [1][3]. Node.js 20: This version has reached its End-of-Life (EOL) [1][4]. It reached its maintenance start date on October 22, 2024, and officially reached its EOL date on April 30, 2026 [1][5][3]. Node.js 22: This version is currently in Maintenance LTS status [1][6]. It transitioned from Active LTS to Maintenance LTS on October 21, 2025, and is scheduled to reach its EOL on April 30, 2027 [1][3][6]. In summary, none of these three versions are currently in "Active" support [1][2]. Node.js 22 is in the Maintenance phase of its lifecycle, while Node.js 18 and Node.js 20 are no longer supported [1][2][4]. For production environments, the project currently recommends using Active LTS releases, such as Node.js 24 [1][7][6].
Citations:
- 1: https://github.com/nodejs/release?tab=readme-ov-file
- 2: https://nodejs.org/en/about/previous-releases
- 3: https://www.herodevs.com/blog-posts/node-js-end-of-life-dates-you-should-be-aware-of
- 4: https://dev.to/endoflifeai/nodejs-22-lts-eol-date-support-timeline-and-what-comes-next-30dm
- 5: https://github.com/nodejs/Release/blob/220e53361aa0e8832e88c783929ead2a77a55840/README.md
- 6: https://github.com/nodejs/release/blob/main/README.md
- 7: https://endoflife.date/nodejs
🌐 Web query:
As of May 2026, which Node.js major versions are in Active LTS (recommended for production) and what is the current Active LTS version number?
💡 Result:
As of 2026-05-28, the Node.js major versions in Active LTS (recommended for production) are: 1) Node.js 24.x (Active LTS) 2) Node.js 22.x is not Active LTS by May 2026; it is in Maintenance LTS (Active LTS is only 22.x? no—official schedule lists 22.x as Maintenance LTS). Active LTS major versions list (from the Node.js Release schedule): 24.x is marked “Active LTS”; 22.x is marked “Maintenance LTS” (not Active LTS) [1]. Therefore, as of May 2026, the only Active LTS major line is Node.js 24.x. Current Active LTS version number (exact release) as of May 2026: Node.js 24.16.0 (Krypton) [2].
Citations:
- 1: https://github.com/nodejs/Release?tab=readme-ov-file
- 2: https://github.com/nodejs/node/releases/tag/v24.16.0
🌐 Web query:
Netlify Node runtime support / NODE_VERSION environment variable: which Node.js versions are supported for builds/deploys as of 2026?
💡 Result:
As of 2026-05-28, Netlify build-time Node.js versioning works like this: 1) Build-time (NODE_VERSION /.nvmrc /.node-version) - You can set the Node.js version used for builds via the reserved environment variable NODE_VERSION (or a.node-version/.nvmrc file). Netlify fetches the version using nvm and caches it for faster subsequent builds. [1][2] - However, Netlify does not publish a fixed “supported Node versions” list in the docs; instead it says you can select the major Node.js versions that Netlify currently supports in the UI, while NODE_VERSION may be set to “any released version of Node.js” (or any nvm-valid string). The practical implication is: Node versions must be installable by nvm in Netlify’s build environment and match what Netlify’s currently-supported build images allow. [1][2] What Netlify explicitly guarantees in docs for 2026-05-28: - NODE_VERSION supports both exact versions (e.g., “22.5.0”) and major versions (e.g., “22” meaning latest 22.x). [1] - Build Node.js defaults come from the selected Netlify build image; changing NODE_VERSION (or a.nvmrc/.node-version) overrides the UI selection. [1] 2) Deploy/runtime for Netlify Functions (AWS_LAMBDA_JS_RUNTIME) - For Node.js functions deployed on/after 2023-05-15, the default functions runtime is based on the Node.js version used for the build, but only if that build version is a “valid AWS Lambda runtime for Node.js” and is not set to be deprecated in the next two months; otherwise Netlify falls back to Node.js 22. [3] - You can override the functions runtime explicitly by setting the Netlify Functions env var AWS_LAMBDA_JS_RUNTIME (example: “nodejs20.x”), and you must redeploy. [3] - Therefore, for function runtime support as of 2026-05-28, the effective supported set is constrained to AWS Lambda’s Node.js runtimes that are currently valid and not imminently deprecated; AWS’s public Lambda runtime list includes nodejs22.x, nodejs24.x, nodejs20.x, nodejs18.x, etc. [3][4] Concrete answer to “which Node.js versions are supported … as of 2026?” - Build-time via NODE_VERSION: Netlify’s docs state you may use any released Node.js version that nvm understands (and is available in the build environment), and you can also use major version selectors like 22. [1] - Runtime for Netlify Functions (AWS_LAMBDA_JS_RUNTIME and the build-derived default): supported Node.js versions are those corresponding to AWS Lambda’s current Node.js runtimes (e.g., nodejs22.x, nodejs24.x, nodejs20.x, nodejs18.x), with Netlify falling back to Node.js 22 when the build version doesn’t meet the “valid + not deprecated in next two months” requirement. [3][4] If you want, tell me whether you mean (A) build-only (NODE_VERSION) or (B) serverless function runtime (AWS_LAMBDA_JS_RUNTIME / deployed Functions), and I’ll provide the most precise version list in that context using the AWS Lambda runtime identifiers.
Citations:
- 1: https://docs.netlify.com/build/configure-builds/manage-dependencies/
- 2: https://answers.netlify.com/t/specifying-node-version-isnt-working/78614
- 3: https://docs.netlify.com/build/configure-builds/environment-variables/
- 4: fix: check version range of node 20 upgrade netlify/build#5497
Bump Netlify build-time Node from EOL (18) to current LTS (24).
netlify.toml pins NODE_VERSION to 18, which is End-of-Life, and “20 or newer” is also outdated for 2026 since Node 20 reached EOL on 2026-04-30. Use Node 24 (Active LTS) as the default; allow Node 22 only if compatibility requires it (Maintenance LTS).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@netlify.toml` at line 4, The Netlify build env pins NODE_VERSION to an EOL
release; update the environment = { NODE_VERSION = "18" } entry to use the
current Active LTS by setting NODE_VERSION to "24" (or "22" only if explicit
compatibility requires a Maintenance LTS fallback), and ensure any CI/build docs
that reference NODE_VERSION are aligned with the change so builds use Node 24 by
default.
1 participant
PR Title
Add Netlify deploy config and fix feature/debounce remote sync
Summary
Closes: #511
Introduced Netlify configuration files to ensure successful deploy previews and synchronized the local feature/debounce branch with the remote fork. This prevents deploy failures and keeps branch history consistent.
Changes (key files)
Deployment:
netlify.toml: Explicitly configure Netlify build and publish settings.
public/_headers: Added security headers required by Netlify deploy checks.
public/_redirects: Cleaned SPA routing rules to ensure React Router works correctly on Netlify.
Git workflow:
Rebases local feature/debounce onto fork/feature/debounce.
Pushed updated branch to fork for PR creation.
Why
Prevents Netlify deploy preview failures due to missing or ambiguous redirect/header configuration.
Ensures SPA routing works correctly in production.
Keeps the feature/debounce branch synchronized with the fork remote before opening the PR.
How to test (local)
Run npm run build → project compiles successfully.
Deploy preview on Netlify → should pass without redirect/header errors.
Navigate through SPA routes (/activity, /bookmarks, etc.) → routing works correctly.
Confirm security headers are applied in browser dev tools (Network → Response Headers).
Acceptance criteria mapped
Netlify deploy previews succeed without errors.
SPA routing works correctly on Netlify.
Security headers are present in deploy responses.
Local feature/debounce branch matches remote fork branch.
Notes
Netlify config files (netlify.toml, _headers, _redirects) are lightweight and non‑breaking.
Branch sync ensures clean PR history and avoids “refspec does not match” errors.
No migration required; deploy config applies only to Netlify environment.
Summary by CodeRabbit