Conversation
|
Would there be value in storing the git sha, since the URL might not contain it? |
ruyadorno
changed the title
integrity for git dependencies
the sha is already what gets stored in the |
|
will restate what I said in the meeting, half in jest but also half seriously: if this feature isn't working in a consistent way that accomplishes what it says it does, entirely removing it is imo potentially a candidate for a patch release. |
while this will not remove the values that are being ignored, it does ensure that we don't throw EINTEGRITY errors for git dependencies which expect a specific integrity value. see npm/rfcs#525
while this will not remove the values that are being ignored, it does ensure that we don't throw EINTEGRITY errors for git dependencies which expect a specific integrity value. see npm/rfcs#525
|
We run into the same problem today and now our ci pipline is stuck, because it does calculate a different hash than any other development machine. If we can help to test this issue, please let us know. The problem came with the upgrade from npm 8.1.2 -> 8.3.1 - so we downgraded and it looks better now. |
|
[email protected] no longer compares the stored integrity field to the generated data |
In npm/rfcs#525 about ignoring `integrity` values in lockfiles it was stated: > the sha is already what gets stored in the resolved field today This is only true for resolutions from non-commits to commits. A dependency like `git://...#4b559c4c663a23f988f6be5094c9a45faf6231bc` will be stored using the same "reference" in `resolved` even when it cloned a branch or a tag that resolved to a different sha. The update is only done if it hasn't been resolved yet, which is already the case if a full "commit" was specified: https://github.com/npm/pacote/blob/4b559c4c663a23f988f6be5094c9a45faf6231bc/lib/git.js#L263-L265 This also applies to `npm ci` after reading `package-lock.json` as it will use the same resolution. This will compare the newly returned commit-hash with a previously set `resolvedSha` and prevent that from happening. Co-authored-by: pacotedev <[email protected]>
5 participants
This is relevant for