fix(core): prevent hangs due to degenerate lockfile diff

[xeger]

What's the problem this PR addresses?

This limits the max edit length for jsdiff, keeping it from taking "forever" with very large lockfiles that have substantial changes. It keeps yarn install --immutable from hanging when the prior lockfile was substantially different from the computed lockfile, and thereby fixes #4405.

...

How did you fix it?

The fix relies on a new maxEditLength option for jsdiff, which is available in jsdiff@5.1.0.

If the max edit length is exceeded, jsdiff returns undefined and Project.ts simply skips the verbose diff output.
...

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

  • CAVEAT: one failing job that I'm stumped on; marked ready to review to gain advice

[arcanis]

That looks good to me, thanks! Until the package is properly released we can try using it with a git protocol (cc @kpdecker)

[xeger]

FWIW @arcanis I'm not sure git protocol ("diff": "git@github.com:kpdecker/jsdiff.git") will work for this case, since the lib requires transpilation + bundling. I will experiment with using patch:` protocol.

[arcanis]

FWIW @arcanis I'm not sure git protocol ("diff": "git@github.com:kpdecker/jsdiff.git") will work for this case, since the lib requires transpilation + bundling. I will experiment with using patch:` protocol.

I think we can just upgrade to the newly published 5.1!
#4405 (comment)

Although as a trivia, Yarn runs the prepack script when cloning repositories. So even if there's transpilation, if the repository is well configured, it should be possible to use git deps 🙂

[xeger]

I don't know 100% that the build will go green, but the one failing job seemingly has nothing to do with my PR - a typescript package's checksum has begun failing. I experimentally freshened it using the latest from npmjs.org -- hopefully this isn't some obscure supply chain attack!

[merceyz]

hopefully this isn't some obscure supply chain attack!

The only difference between the two is that one is better compressed than the other, otherwise their content is identical. Same thing happens on master though this suddenly changing is worrying.

[arcanis]

The only difference between the two is that one is better compressed than the other, otherwise their content is identical. Same thing happens on master though this suddenly changing is worrying.

Hm perhaps you installed TS 4.7 in a project which had a compression set to 0, which led to the package being added as such into the global cache; then when you upgraded it into the Yarn repo it pulled the 0-compression archive from the global cache and put it in the local one.

However this shouldn't be possible because we append a cache key to the global path, and the compression level is part of it 🤔

[merceyz]

Yeah, that shouldn't be possible, besides the size difference isn't enough for that to be the case.

-11 652 885 bytes
+11 654 629 bytes

[merceyz]

@arcanis It was caused by 2c260ca, it merged in the zip file generated for v3 which doesn't use zlib-ng.