Updates parsing of yarn.lock to use resolved URLs that are pulled from yarn and npm registries

[AMoo-Miki]

Signed-off-by: Miki amoo_miki@yahoo.com

The changes include:

• making the parser only look for resolved URLs in yarn.lock files
• creating a fixture of yarn workspace with skeleton dependencies
• updating integration tests in TestYarnPackageLockDirectory validate the results against the fixture
• remove old yarn artifacts

Resolves

#925

[wagoodman]

Clever fix! 🙌

I think the only caveat I see is that using the resolved URL will only match in cases where there is a match with yarnpkg.com or npmjs.org which means that self-hosts/alternative hosting of packages won't be able to leverage the URL.

[wagoodman]

Question about conflicts, from the existing test fixture:

c0n-fab_u.laTION@^7.0.0:
  version "7.7.7"
  resolved "https://registry.yarnpkg.com/something-i-made-up/-/c0n-fab_u.laTION-7.7.7.tgz#b9c2bf5805f1e64aadeed6df3a2bfafb5a73f5a0"
  integrity sha512-p32cOF5q0Zqs9uBiONKYLm6BClCoBCM5O9JfeUSlnQLBTxYdTK+pW+nXflm8UkKd2UYlEbYz5qEi0JuZR9ckSw==

What is the right value here for the package name? c0n-fab_u.laTION or something-i-made-up ? Should we require that the outer package name (in this case c0n-fab_u.laTION) be a substring of the name extracted from the resolved URL? And if it's not a substring, default to the outer package name?

[AMoo-Miki]

I think the only caveat I see is that using the resolved URL will only match in cases where there is a match with yarnpkg.com or npmjs.org which means that self-hosts/alternative hosting of packages won't be able to leverage the URL.

Correct. For them, it will simply fallback to the name inferred from the identifier. If we find another registry with standardized naming conventions, the regex can be updated.

What is the right value here for the package name?

While I haven't seen a spec doc for the naming convention used, all the resolved URLs I have seen from NPM and Yarn registries have @scope/name/-/name in them. While I am sure there are millions of package-versions on these registries, I have tested the pattern against over 4000 of them. From what i gather, the first @scope/name is what the package confesses to be and the second name (everything after /-/) is to avoid conflicts when downloading the archives prior to an install.

Of course , short of a spec doc from the registries, my 4000 cases of validation are not proof enough that an NPM/Yarn URL with a different structure doesn't exist. However, I think it is a strong indication that we shouldn't expect to see them.

We have 3 options here:

1. Continue to rely on @scope/name/-/whatever and handle problems when someone raises an issue.
2. Change pattern to (@scope)/(name)/-/($2) which will fallback to the inferred name if whatever doesn't match name.
3. Change pattern to (@scope)/(name)/-/(another-name) and simply throw a warning about the package name not matching what we expected but continue to use @scope/name with the hopes that user will raise an issue asking about it.

While I think option 1 is perfect because I don't care for "whatever", I think option 2 will not detract from it but option 3 will encourage feedback.

PS, I will look into the unit test failure.

[spiffcs]

Approved - I'm updating the unit tests on this now