Well, now I'm even more confused:

2026-04-07T07:15:38.9532090Z #64 125.8 npm error `npm ci` can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with `npm install` before continuing.
2026-04-07T07:15:38.9537843Z #64 125.8 npm error
2026-04-07T07:15:38.9538287Z #64 125.8 npm error Missing: @swc/helpers@0.5.21 from lock file
2026-04-07T07:15:38.9538880Z #64 125.8 npm error Missing: tslib@2.8.1 from lock file

Okay one image build succeeded, one failed because of an unsuccessful SSL/TLS handshake. Re-running.

Well, the image builds this PR was supposed to fix are failing because of the error above.

Okay I tried pinning to 2019.7.3 instead, but that resulted in:

161.3 npm error `npm ci` can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with `npm install` before continuing.
161.3 npm error
161.3 npm error Invalid: lock file's @types/offscreencanvas@2019.7.0 does not satisfy @types/offscreencanvas@2019.7.3
161.3 npm error Missing: @swc/helpers@0.5.21 from lock file
161.3 npm error Missing: tslib@2.8.1 from lock file

So yeah, we apparently need even more doctoring to get this fixed. npm is just very, very weird :/

So currently we decided to play whack-a-mole with patches, which I think is a good approach if we want to try to guarantee we use the same dependencies as upstream used when building the product. It is annoying however.

The problem seems to be that the lockfile is somewhat broken and does not pin all dependencies correctly.

It seems like NPM has fixed some bugs related to lockfile generation in newer versions (e.g. npm/cli#8981). So what we could try to do: regenerate package-lock.json with the latest version of NPM and commit that as a patch (will be a huge diff though). And then use that NPM version inside the Dockerfile to build the Superset frontend. That might remove the need for playing whack-a-mole with dependency pinning.

That approach definitely also crossed my mind. I can first try to only use a newer npm version before regenerating the whole lock file.

You can try it, but I think the problem is that the lockfile does not lock everything properly 😕 With a newer version the lockfile should contain more dependencies.

You can try it

I tried, and failed. Re-generating the lock file fixed it.