fix(docker): install the dev frontend from the lockfile

[devin-ai-integration]

SUMMARY

docker/docker-frontend.sh:36 ran a bare npm install. That resolves dependency versions afresh at container start and ignores superset-frontend/package-lock.json, so a dev container started today can install a package version published minutes ago and never reviewed here. The non-dev build path already installs from the lockfile (Dockerfile:75, npm ci); this change makes the in-container dev path do the same.

The diff is three lines: npm install becomes npm ci, with a comment stating why. No lockfile-less install is required at that point in the script — the lockfile is present in the bind-mounted superset-frontend directory, and npm ci resolves against it.

Behaviour this changes, beyond version pinning:

• npm ci deletes node_modules and reinstalls from scratch on every container start. superset-frontend is bind-mounted from the host (docker-compose.yml:33), so the host's node_modules is wiped and rebuilt each time superset-node starts, where npm install was close to a no-op on repeat starts. Measured cost with a warm npm cache: added 3020 packages, and audited 3056 packages in 1m.
• npm ci fails hard when package.json and package-lock.json drift, instead of silently resolving something new. With set -e at the top of the script, that surfaces as the superset-node container exiting before the webpack dev server starts, rather than as a dev server running against unreviewed versions. This is the intended trade, but it is a change in failure mode.
• NPM_RUN_PRUNE=true still works. npm run prune removes ./{packages,plugins}/*/{node_modules,lib,esm,tsconfig.tsbuildinfo,package-lock.json}; the root package-lock.json that npm ci needs is untouched.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Not applicable — no UI change.

TESTING INSTRUCTIONS

Evidence below was produced against this branch on node:24-trixie-slim, the base image the dev frontend container uses (Dockerfile:32), with superset-frontend's package.json, package-lock.json, and all workspace package.json files and no pre-existing node_modules — i.e. the post-npm run prune state.

1. npm ci resolves against the committed lockfile:

$ docker run --rm -v /home/ubuntu/fe-ci-check:/app/superset-frontend \
    -w /app/superset-frontend node:24-trixie-slim sh -c 'node -v; npm -v; npm ci'
v24.19.0
11.17.0
added 3020 packages, and audited 3056 packages in 1m

2. Installed versions match the lockfile. For every non-link node_modules/* entry in package-lock.json, the installed package's own package.json version was compared to the locked version:

checked 2974 installed packages against lockfile; mismatches: 0

(The 3020 − 2974 difference is lockfile entries with no version field or no installed package.json to read, e.g. platform-specific optional packages resolved for other architectures.)

3. Lint (pre-commit, per AGENTS.md), with docker/docker-frontend.sh staged:

$ pre-commit run
check for added large files..............................................Passed
fix end of files.........................................................Passed
trim trailing whitespace.................................................Passed
[all other hooks: (no files to check)Skipped]

$ bash -n docker/docker-frontend.sh
bash -n: ok

shellcheck is not installed in this environment and is not a pre-commit hook in this repo, so the script was only syntax-checked.

4. Tests. No test in this repository exercises docker/docker-frontend.sh; there is no shell-script test target. The frontend Jest harness was run as a smoke check that the change did not disturb it:

$ cd superset-frontend && npm run test -- src/utils/assetUrl.test.ts
PASS src/utils/assetUrl.test.ts (6.895 s)
Test Suites: 1 passed, 1 total
Tests:       10 passed, 10 total

Manual verification of the full path:

docker compose up superset-node

Expect Running "npm ci" in the log, followed by the webpack dev server on http://localhost:9000.

Limitations of the evidence:

• npm ci was verified in the same base image with the same manifests, not by starting superset-node under docker compose, so the full dev stack was not brought up.
• The lockfile-drift failure mode was observed incidentally, not as a designed test: npm ci on this machine's host toolchain (node v20.18.1 / npm 10.8.2) reports Missing: @noble/hashes@1.8.0 from lock file and Missing: dompurify@3.4.13 from lock file. The same command on the container's pinned toolchain (node v24.19.0 / npm 11.17.0, matching engines: node ^24.16.0, npm ^11.13.0) succeeds. Contributors running npm ci on an npm older than the pinned major will see spurious drift errors; inside the container, which is what this script governs, the toolchain is pinned and correct.

Adversarial self-review of the diff — what was checked and what was found:

• Does the lockfile actually satisfy npm ci at this commit? Yes on the pinned toolchain; no on npm 10. Recorded above.
• Does npm run prune remove something npm ci needs? No. It deletes workspace-level lockfiles, not the root one; the test ran in exactly that state.
• Does anything else invoke this script and depend on npm install's add-a-package behaviour? docker-compose.yml:211 and docker-compose-light.yml:176 invoke it as a container command; neither passes package names, and the script installs no packages beyond the manifests.
• Does the script still fail closed? Yes. set -e (line 18) means a failed npm ci stops before npm run dev-server.
• Was the npm install in Dockerfile touched? No. It was already npm ci; this branch changes one file.
• Comment wording checked against the AGENTS.md rule against time-specific language ("now", "currently") — the comment contains none.

ADDITIONAL INFORMATION

• Has associated issue: Fixes fix(docker): docker-frontend.sh uses bare npm install, bypassing the lockfile #26
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

AI DISCLOSURE

This change was authored with AI assistance (Devin). A human reviews it before merge.

AUTHOR'S NOTE

Link to Devin session: https://app.devin.ai/sessions/cc4b160760994e49a6e20054fc9d4934
Requested by: @jethac

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[jethac]

Upstream issue filed: apache#42979

Verified against apache/superset@3539c41dab before filing, so the defect this PR fixes is confirmed present on upstream master and not only on the fork.

[jethac]

Superseded by #33.

Its sole change — npm install to npm ci in docker/docker-frontend.sh — is already in #33, which pairs it with the .npmrc cooldown files that motivate installing from the lockfile. #42's explanatory comment is better and should be carried over to #33.

Closing in favour of #33. Reviewed together with the other open PRs on this fork; reopen if this was the wrong call.