chore(deps): update mcr.microsoft.com/vscode/devcontainers/typescript-node docker tag to v24#25
Conversation
|
@kyoto is it safe to merge? |
…-node docker tag to v24 Signed-off-by: red-hat-konflux <126015336+red-hat-konflux[bot]@users.noreply.github.com>
a874703 to
ce9b189
Compare
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe devcontainer plugin Dockerfile now uses ChangesDevcontainer image bump
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
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 @.devcontainer/Dockerfile.plugin:
- Line 1: The devcontainer base image is using Node 24, which is outside the
supported range for the direct dev dependency i18next-parser. Update the FROM
image in Dockerfile.plugin to a Node 22 devcontainer (or, if Node 24 is
required, first update i18next-parser/tooling to a version that explicitly
supports it) so the devcontainer stays aligned with the repo toolchain.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 4c62801c-5a27-4c14-af72-0e00f05b53c4
📒 Files selected for processing (1)
.devcontainer/Dockerfile.plugin
| @@ -1,2 +1,2 @@ | |||
| FROM mcr.microsoft.com/vscode/devcontainers/typescript-node:16 as build | |||
| FROM mcr.microsoft.com/vscode/devcontainers/typescript-node:24 as build | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n '"engines"|"node"|node-gyp|prebuild|npm ci' package.json .devcontainerRepository: openshift/lightspeed-agentic-console
Length of output: 319
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== files ==\n'
git ls-files .devcontainer/Dockerfile.plugin .devcontainer/devcontainer.json package.json
printf '\n== package.json excerpt ==\n'
if [ -f package.json ]; then
wc -l package.json
sed -n '1,220p' package.json
fi
printf '\n== devcontainer files ==\n'
for f in .devcontainer/Dockerfile.plugin .devcontainer/devcontainer.json; do
if [ -f "$f" ]; then
echo "--- $f"
wc -l "$f"
sed -n '1,220p' "$f"
fi
doneRepository: openshift/lightspeed-agentic-console
Length of output: 5468
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Search for any Node/version-sensitive tooling or native addon indicators.
rg -n --hidden --glob '!.git' --glob '!**/node_modules/**' \
'engines|node-gyp|prebuild|prebuildify|node-version|\.nvmrc|\.tool-versions|npm ci|npm install|npm rebuild|sass|sharp|canvas|bcrypt|sqlite3|fsevents' \
.devcontainer package.json .Repository: openshift/lightspeed-agentic-console
Length of output: 42724
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== files ==\n'
git ls-files .devcontainer/Dockerfile.plugin .devcontainer/devcontainer.json package.json
printf '\n== package.json excerpt ==\n'
if [ -f package.json ]; then
wc -l package.json
sed -n '1,220p' package.json
fi
printf '\n== devcontainer files ==\n'
for f in .devcontainer/Dockerfile.plugin .devcontainer/devcontainer.json; do
if [ -f "$f" ]; then
echo "--- $f"
wc -l "$f"
sed -n '1,220p' "$f"
fi
doneRepository: openshift/lightspeed-agentic-console
Length of output: 5468
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Search for any Node/version-sensitive tooling or native addon indicators.
rg -n --hidden --glob '!.git' --glob '!**/node_modules/**' \
'engines|node-gyp|prebuild|prebuildify|node-version|\.nvmrc|\.tool-versions|npm ci|npm install|npm rebuild|sass|sharp|canvas|bcrypt|sqlite3|fsevents' \
.devcontainer package.json .Repository: openshift/lightspeed-agentic-console
Length of output: 42724
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
import json, re, sys
from pathlib import Path
pkg = json.loads(Path("package.json").read_text())
lock = json.loads(Path("package-lock.json").read_text())
print("package.json engines:", pkg.get("engines"))
# Direct dependencies from package.json
deps = {}
for section in ("dependencies", "devDependencies"):
deps.update(pkg.get(section, {}))
lock_pkgs = lock.get("packages", {})
root = lock_pkgs.get("", {})
print("package-lock root engines:", root.get("engines"))
# Show direct deps that have engine declarations in lockfile.
print("\nDirect deps with engine declarations:")
for name, ver in sorted(deps.items()):
path = f"node_modules/{name}"
meta = lock_pkgs.get(path)
if meta and "engines" in meta:
print(f"- {name}@{ver}: {meta['engines']}")
# Find any packages whose engines explicitly exclude Node 24.
def excludes_node24(eng):
if not eng:
return False
node = eng.get("node")
if not node:
return False
# Simple conservative checks for common upper-bound patterns.
s = str(node)
if re.search(r'(<\s*24(\.0\.0)?\b)|(<\s*25\b)|(\b<=\s*23\b)|(\b<\s*23\b)', s):
return True
# exact disallow list patterns like ">=16 <24"
if re.search(r'<\s*24\b', s):
return True
return False
bad = []
for path, meta in lock_pkgs.items():
if path == "":
continue
if excludes_node24(meta.get("engines")):
bad.append((path, meta.get("engines")))
print("\nPackages with node engine ranges that appear to exclude Node 24:")
for path, eng in bad[:80]:
print(f"- {path}: {eng}")
print(f"count={len(bad)}")
PYRepository: openshift/lightspeed-agentic-console
Length of output: 2151
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the root package metadata in package-lock.json for workspace/package manager hints.
python3 - <<'PY'
import json
from pathlib import Path
lock = json.loads(Path("package-lock.json").read_text())
print("lockfileVersion:", lock.get("lockfileVersion"))
print("packages[''] keys:", sorted(lock.get("packages", {}).get("", {}).keys()))
print("root package entry:", json.dumps(lock.get("packages", {}).get("", {}), indent=2)[:3000])
PYRepository: openshift/lightspeed-agentic-console
Length of output: 2225
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Check whether installs are configured to fail on engine mismatches.
rg -n --hidden --glob '!.git' --glob '!**/node_modules/**' \
'engine-strict|strict-ssl|npm config|NPM_CONFIG_ENGINE_STRICT|NODE_OPTIONS|npm ci|postCreateCommand|devcontainer' \
. .devcontainer package.json package-lock.json .npmrc .npmrc* 2>/dev/null || true
printf '\n== npmrc files ==\n'
git ls-files '.npmrc' '.devcontainer/.npmrc' '.npmrc.*' 2>/dev/null || trueRepository: openshift/lightspeed-agentic-console
Length of output: 2730
🌐 Web query:
npm ci engine-strict default behavior package engines warnings fail install official docs
💡 Result:
By default, the engines field in package.json is advisory only and does not cause npm install or npm ci to fail [1]. When the engines requirements are not met, npm will typically emit a warning but proceed with the installation [2][3][1]. The engine-strict configuration flag (default: false) is the mechanism to change this behavior [4][5]. If engine-strict is set to true, npm is instructed to strictly enforce the engines requirements, causing it to refuse to install or proceed if a package is incompatible with the current Node.js or npm version [4][5]. Regarding npm ci specifically: - When engine-strict is enabled (set to true), npm ci is designed to respect this flag and will fail the installation with an EBADENGINE error if the engine requirements are not satisfied [6]. - When engine-strict is false (the default), npm ci will generally follow the advisory nature of engines, emitting warnings rather than failing the process [3][1]. If you need to enforce engine compatibility in your project, you can set engine-strict=true in your project's.npmrc file [7][2].
Citations:
- 1: https://docs.npmjs.com/cli/v10/configuring-npm/package-json/
- 2: [BUG] Engines property not working npm/cli#692
- 3: RFC for check engines requirements on every install npm/rfcs#195
- 4: https://docs.npmjs.com/cli/v9/using-npm/config/
- 5: https://docs.npmjs.com/cli/v6/using-npm/config/
- 6: [BUG] unable to install latest versions of transitive dependencies, overrides & engine requirements silently ignored npm/cli#8863
- 7: npm ci used with engine-strict true doesn't work as npm install npm/cli#1219
🌐 Web query:
npm ci engine-strict default behavior package engines warnings fail install official docs
💡 Result:
The default behavior of the engines field in package.json is purely advisory [1][2]. When engine-strict is set to its default value of false, npm will not fail an installation if a package's engine requirements (e.g., node or npm version) are not met; it will typically only issue a warning [1][2][3]. If you set engine-strict to true (e.g., in a .npmrc file), npm will strictly enforce these requirements and fail the installation—producing an EBADENGINE error—if the current environment does not satisfy them [4][5][6]. Key considerations regarding this behavior: - Scope: The engine-strict configuration flag applies to both npm install and npm ci [5]. - Intent: The engines field is designed to inform users of compatibility requirements, not to act as a hard block during standard operations unless explicitly configured to do so [1][2]. - Overrides: Using the --force flag during installation can override engine-strict behavior, allowing the installation to proceed even if requirements are not met [4]. - Potential Issues: There have been reports and discussions regarding the interaction between engine-strict, devEngines, and different npm versions, where some users have observed inconsistent enforcement [7][5][8]. To enforce environment requirements in a project, it is recommended to set engine-strict=true in a project-level .npmrc file [9][3].
Citations:
- 1: https://docs.npmjs.com/files/package.json/
- 2: https://docs.npmjs.com/cli/v9/configuring-npm/package-json/
- 3: [BUG] Engines property not working npm/cli#692
- 4: https://docs.npmjs.com/cli/v9/using-npm/config/
- 5: npm ci used with engine-strict true doesn't work as npm install npm/cli#1219
- 6: https://techqa.club/v/q/updating-npm-requires-new-version-of-npm-deadlock-with-engines-requirement-in-package-json-72112302
- 7: [BUG] Presence of devEngines in package.json disables engine-strict checks npm/cli#7888
- 8: [BUG] unable to install latest versions of transitive dependencies, overrides & engine requirements silently ignored npm/cli#8863
- 9: [BUG]
enginesinpackage.jsondoesn't work npm/cli#6845
Pin Node 22 or update i18next-parser.
i18next-parser is a direct dev dependency and only declares support through Node 22, so this image is outside one of the repo’s toolchain ranges. npm ci won’t fail on engines by default, but the devcontainer is not fully Node 24-compatible yet.
🧰 Tools
🪛 Trivy (0.69.3)
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
🤖 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 @.devcontainer/Dockerfile.plugin at line 1, The devcontainer base image is
using Node 24, which is outside the supported range for the direct dev
dependency i18next-parser. Update the FROM image in Dockerfile.plugin to a Node
22 devcontainer (or, if Node 24 is required, first update i18next-parser/tooling
to a version that explicitly supports it) so the devcontainer stays aligned with
the repo toolchain.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
This PR contains the following updates:
16→24Configuration
📅 Schedule: (in timezone UTC)
* * * * *)🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
To execute skipped test pipelines write comment
/ok-to-test.Documentation
Find out how to configure dependency updates in MintMaker documentation or see all available configuration options in Renovate documentation.