chore(docker): bump node from 18-alpine to 26-alpine#120
chore(docker): bump node from 18-alpine to 26-alpine#120dependabot[bot] wants to merge 1 commit into
Conversation
Bumps node from 18-alpine to 26-alpine. --- updated-dependencies: - dependency-name: node dependency-version: 26-alpine dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughThe Dockerfile's multi-stage build base image was upgraded from Node 18 Alpine to Node 26 Alpine. All build stages ( ChangesNode.js Base Image Upgrade
🎯 1 (Trivial) | ⏱️ ~2 minutes
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsThese MCP integrations need to be re-authenticated in the Integrations settings: Sentry, Sentry Comment |
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@Dockerfile`:
- Line 2: Update the base image in the Dockerfile from the current Node 26 image
to the Node 24 LTS image to ensure production stability: replace the FROM
node:26-alpine AS base reference with a Node 24 LTS alpine variant (e.g.,
node:24-alpine) and rebuild/test the image, then run your test suite (especially
any HTTP/stream-related tests) to validate dependencies against Node 24 while
keeping the existing production NODE_ENV settings.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ea1cf174-0e29-4b10-8481-748bdb6fb1c7
📒 Files selected for processing (1)
Dockerfile
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: lint
- GitHub Check: npm-audit
- GitHub Check: Analyze (javascript-typescript)
🧰 Additional context used
🔍 Remote MCP
Let me search for additional information about Node 18 end-of-life status and production readiness of Node 26.## Summary of Relevant Context for PR Review
Node.js Version Lifecycle Context
Node.js 18 and all earlier versions are End-Of-Life and completely unsupported, meaning they receive no updates, including security patches, with immediate and serious security implications. Node.js 18.x reached its End of Life support on April 30, 2025, and the Node.js community no longer provides bug fixes or security updates for this version.
Node.js 26 Release Status & Characteristics
Node.js 26 launched as a Current release, not a Long-Term Support (LTS) release. After roughly six months as Current, it transitions to Active LTS status, with Node.js 26 scheduled to enter LTS in October 2026. Node.js 26 is best suited for development environments and testing until it reaches LTS status. For production applications that require stability, Node.js 24 is the current Active LTS release and Node.js 22 is in Maintenance LTS.
Breaking Changes in Node.js 26
The upgrade introduces several significant breaking changes that require review:
-
Stream Module Deprecations: Any package that requires legacy stream modules directly will break on Node.js 26, with the correct replacement being to import from the stream module: require('stream').Readable, require('stream').Writable, etc.
-
Stream Buffering Behavior: Readable streams change behavior in Node.js 26: they now read one buffer at a time instead of reading ahead. Applications that depend on the old buffering behavior may experience changes in throughput, and stream-heavy code paths should be tested before upgrading in production.
-
HTTP API Changes: http.Server.prototype.writeHeader() has been removed; applications must use writeHead().
-
Testing Recommendation: Running your test suite against a Node.js 26 environment is the most reliable way to surface incompatibilities before they reach production.
Next.js Compatibility
Next.js requires a minimum Node.js version of 20.9. Next.js is compatible with Node.js 26 from a version requirement perspective, but the broader ecosystem impact should be validated.
[::web_search::]
| @@ -1,5 +1,5 @@ | |||
| # Base stage for shared dependencies | |||
| FROM node:18-alpine AS base | |||
| FROM node:26-alpine AS base | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Build and test the application with Node.js 26 to identify compatibility issues
# Build the Docker image with Node.js 26
docker build -t test-node26 -f Dockerfile .
# Run the application container in detached mode
docker run -d -p 3000:3000 --name test-node26-container test-node26
# Wait for the application to start
sleep 10
# Check if the application is running
if docker ps | grep -q test-node26-container; then
echo "✓ Container started successfully"
# Test if the application responds on port 3000
if curl -f http://localhost:3000 > /dev/null 2>&1; then
echo "✓ Application responds on port 3000"
else
echo "✗ Application does not respond on port 3000"
docker logs test-node26-container
fi
else
echo "✗ Container failed to start"
docker logs test-node26-container
fi
# Cleanup
docker stop test-node26-container 2>/dev/null || true
docker rm test-node26-container 2>/dev/null || true
docker rmi test-node26 2>/dev/null || trueRepository: GrayGhostDev/Midway_Cleaning_app
Length of output: 304
🏁 Script executed:
cat DockerfileRepository: GrayGhostDev/Midway_Cleaning_app
Length of output: 961
🌐 Web query:
Node.js 26 release status LTS timeline 2026
💡 Result:
Node.js 26 release status and LTS timeline (as of 2026-05-11): 1) Current vs LTS status - Node.js v26.0.0 launched as the “Current” release on 2026-05-05, and it is scheduled to enter long-term support (LTS) in October 2026 (i.e., it is not yet LTS as of 2026-05-11) [1]. 2) Authoritative LTS timeline for the v26 line (existing schedule) - 26.0.0 (initial/current release line): April 2026 [2] - Enters LTS: October 2026 [2] - Maintenance start: October 2027 [2] - End of Life (EOL): April 2029 [2] Notes on “release schedule” changes affecting later versions - Node.js announced an updated release schedule starting with 27.x: previously there were two major releases per year (April/October), but under the new model there will be one major release per year (April), and “every release becomes LTS” (no more odd/even distinction) [2]. Node.js 26 is explicitly shown as following the “existing model” timeline above [2]. Practical takeaway for 2026 - If you need an LTS for production during 2026, Node.js 26 won’t become LTS until October 2026; until then it’s “Current” [1][2].
Citations:
- 1: https://github.com/nodejs/node/releases/tag/v26.0.0
- 2: https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule
🌐 Web query:
Node.js 24 LTS active release status
💡 Result:
As of 2026-05-11, Node.js 24 is on Active LTS. Node.js 24.x (“Krypton”) entered Active LTS on 2025-05-06 and remains in Active LTS until 2026-10-20, after which it transitions to Maintenance LTS and continues until end-of-life on 2028-04-30.[1][2] Source-backed summary: Node.js releases list v24 as “Active LTS”, and the official nodejs/Release repository specifies the Active LTS and end-of-life dates for 24.x.[2][1]
Citations:
🌐 Web query:
Node.js 26 breaking changes stream HTTP API
💡 Result:
Node.js 26 (released 2026-05-05) contains a few semver-major removals and HTTP/stream-related behavior changes that can break existing code, especially if you rely on internal/legacy APIs. 1) stream: legacy internal stream* modules removed (breaks require/import) Node.js 26 fully removed the legacy internal stream modules: _stream_wrap, _stream_readable, _stream_writable, _stream_duplex, _stream_transform, and _stream_passthrough. If your code (or a dependency) imports these internals directly, it will fail at runtime or install time. [1][2] 2) http: http.Server.prototype.writeHeader removed; use writeHead Node.js 26 removed http.Server.prototype.writeHeader. The release notes state to use http.Server.prototype.writeHead instead. [1] 3) stream: web-streams AbortSignal wiring changed (behavioral change) For Node’s Web Streams integration, stream.addAbortSignal behavior was fixed/changed so that the writable side uses abort semantics (and aborts the controller/signal) instead of error-only semantics. The PR explains that for WritableStream it wires the abort path (and effects like cancel/abort behavior and different promise rejection timing) rather than controller.error. This can change observable behavior for code depending on how abort vs error propagates. [3] 4) undici (Node’s fetch/HTTP client): Undici 8 shipped (can introduce HTTP client breaking changes) The Node.js 26 release includes Undici 8 (updated to 8.0.2 per the release notes). [1] If you use Undici/Node fetch interception hooks (custom dispatchers/interceptors), Undici 8 included refactoring and dropping of some legacy handler/interceptor interface; a Node issue discusses interception breaking when updating to Undici 8 and notes it as fixed by v8.0.1 for that case. [4] Bottom line for “Node.js 26 breaking changes stream HTTP API” - If you use legacy HTTP server API: replace writeHeader with writeHead. [1] - If you (or deps) import stream* internal modules: update to public stream APIs (e.g., require('stream').Readable/Writable/etc.). [1][2] - If you use addAbortSignal / web streams: re-test abort/error handling paths after upgrade; semantics differ for the web streams implementation. [3] - If you use fetch/Undici interception/custom dispatchers: re-test and check for compatibility with Undici 8’s interception/dispatcher changes. [1][4] Top sources (most relevant) [1] https://github.com/nodejs/node/releases/tag/v26.0.0 [2] nodejs/node#60657 [3] nodejs/node#62450 [4] nodejs/node#62351
Citations:
- 1: https://github.com/nodejs/node/releases/tag/v26.0.0
- 2: stream: move _stream_* to end-of-life nodejs/node#60657
- 3: stream: fix addAbortSignal() for web streams nodejs/node#62450
- 4: undici 8 update nodejs/node#62351
🌐 Web query:
Next.js Node.js 26 compatibility requirements
💡 Result:
Next.js (current docs for v16 and the Next.js repo) requires Node.js 20.9.0+; therefore Node.js 26 is compatible as it is >= 20.9.0. This is the minimum runtime/version requirement you must satisfy when building/running Next.js on Node.js 26. Notes for compatibility: 1) Minimum Node.js version: Next.js 16’s version requirements state “Node.js 20.9+” with minimum version 20.9.0 [1]. The Next.js repo change also updates package engines to “>=20.9.0” [2]. 2) Node.js 26 itself: Node.js 26.0.0 is a Current release (not LTS), but that doesn’t change the Next.js minimum requirement—only whether it’s a stability track choice for production [3]. 3) Platform/runtime implication: Next.js deployment platforms need “a Node.js server” [4]. If you self-host, Next.js supports Node.js runtime features like streaming when using the App Router; your reverse proxy must be configured to disable buffering if you rely on streaming [5]. Actionable checklist to use Next.js with Node.js 26 (2026-05-11): - Use Node.js 20.9.0+ (Node.js 26 meets this) [1]. - If you self-host behind a proxy (nginx), ensure buffering is disabled to preserve streaming behavior [5]. - Still run your app’s test/build with Node.js 26 because transitive dependencies (not Next.js itself) are what commonly break across major Node upgrades—Next.js only guarantees compatibility to its declared minimum and supported range, not that every third-party package will work on a brand-new Node major.
Citations:
- 1: https://nextjs.org/docs/app/guides/upgrading/version-16
- 2: vercel/next.js@11762a7
- 3: https://nodejs.org/en/blog/release/v26.0.0
- 4: https://nextjs.org/docs/app/guides/deploying-to-platforms
- 5: https://nextjs.org/docs/15/app/guides/self-hosting
Reconsider using Node.js 26 Current release for production; prefer Node.js 24 LTS.
Node.js 26 is a Current release that won't enter LTS status until October 2026. Current releases are designed for development and testing, not production stability. For a production application (indicated by NODE_ENV=production), Node.js 24 is the recommended Active LTS release that provides long-term stability and security support.
Additionally, Node.js 26 introduces breaking changes that require validation:
- Stream module removals: Legacy internal stream modules (
_stream_readable,_stream_writable, etc.) have been fully removed. Packages importing these internals will fail. - HTTP API removal:
http.Server.prototype.writeHeader()has been removed; usewriteHead()instead. - Stream AbortSignal behavior change: The semantics of
stream.addAbortSignal()for web streams differ, affecting abort vs. error propagation paths.
The primary risk during upgrade is transitive dependencies breaking on Node.js 26, not Next.js itself (which supports Node.js 20.9+).
🔄 Recommended approach
Consider these options in priority order:
Option 1 (Recommended for production): Use Node.js 24 LTS
-FROM node:26-alpine AS base
+FROM node:24-alpine AS baseOption 2 (If Node.js 26 features are required): Wait until October 2026 when Node.js 26 enters LTS, or accept the stability trade-offs and thoroughly test the application.
Run comprehensive tests to validate compatibility with Node.js 26, particularly focusing on dependencies and HTTP/stream usage patterns. Ensure your test suite covers stream operations and HTTP server interactions.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| FROM node:26-alpine AS base | |
| FROM node:24-alpine AS base |
🤖 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 `@Dockerfile` at line 2, Update the base image in the Dockerfile from the
current Node 26 image to the Node 24 LTS image to ensure production stability:
replace the FROM node:26-alpine AS base reference with a Node 24 LTS alpine
variant (e.g., node:24-alpine) and rebuild/test the image, then run your test
suite (especially any HTTP/stream-related tests) to validate dependencies
against Node 24 while keeping the existing production NODE_ENV settings.
Bumps node from 18-alpine to 26-alpine.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)Summary by CodeRabbit