fix(superset): Patch pinned packages and re-generate lock file#1456
fix(superset): Patch pinned packages and re-generate lock file#1456
Conversation
|
Well, now I'm even more confused: |
|
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: 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 |
|
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. |
I tried, and failed. Re-generating the lock file fixed it. |
NickLarsenNZ
left a comment
There was a problem hiding this comment.
LGTM, but I would recommend using the container image (also keeps the Dockerfile simpler)
This PR pins the
@types/offscreencanvaspackage of Superset (frontend) 4.1.4 to 2019.7.0 in order to fix the following issue encountered since the last few scheduled CI runs. Additionally, it adds a patch with a re-generated package-lock.json file which fully fixes the following error:This error is very similar to errors fixed in #1363, #1315, and #1316. This is a known weakness/bug in npm.
Test builds in CI: