[Bug?]: <package> isn't supported by any available resolver - when migrating from yarn@1 #5156
Description
Self-service
- I'd be willing to implement a fix
Describe the bug
Hi,
we have internal artifactory, which mirrors external + publishes some @scoped packages. When following migration steps from https://yarnpkg.com/getting-started/migration I'm getting following error:
➤ YN0001: │ Error: @company/some-package@npm:^46.0.29: @company/some-package@npm:46.0.29::__archiveUrl=https%3A%2F%2Fartifactory.corp%3A443%2Fartifactory%2Fapi%2Fnpm%2Fvirtual-node%2F%40company%2Fsome-package%2F-%2F%40company%2Fsome-package-46.0.29.tgz%23 isn't supported by any available resolver
at zf.getResolverByDescriptor (.yarn/releases/yarn-3.3.1.cjs:391:1647)
at zf.getCandidates (.yarn/releases/yarn-3.3.1.cjs:391:1235)
at pb.getCandidates (.yarn/releases/yarn-3.3.1.cjs:435:3324)
at zf.getCandidates (.yarn/releases/yarn-3.3.1.cjs:391:1264)
at .yarn/releases/yarn-3.3.1.cjs:439:7695
at Ff (.yarn/releases/yarn-3.3.1.cjs:390:8965)
at ge (.yarn/releases/yarn-3.3.1.cjs:439:7675)
I have more or less managed to trace down issue to this line: https://github.com/yarnpkg/berry/blob/%40yarnpkg/core/3.3.1/packages/yarnpkg-core/sources/LegacyMigrationResolver.ts#L20-L22
After applying following patch, building locally and replacing yarn.js I don't get this error anymore and everything works:
Index: packages/yarnpkg-core/tests/LegacyMigrationResolver.test.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/packages/yarnpkg-core/tests/LegacyMigrationResolver.test.ts b/packages/yarnpkg-core/tests/LegacyMigrationResolver.test.ts
--- a/packages/yarnpkg-core/tests/LegacyMigrationResolver.test.ts (revision 3246d10cdcdcb6ffdb297e09a360a311c951396a)
+++ b/packages/yarnpkg-core/tests/LegacyMigrationResolver.test.ts (date 1671781469810)
@@ -18,13 +18,13 @@
{
version: `1.0.0`,
resolved: `https://company.jfrog.io/company/api/npm/registry-name/@scope/package-name/-/@scope/package-name-1.0.0.tgz#eeeec1e4e8850bed0468f938292b06cda793bf34`,
- expected: `npm:1.0.0::__archiveUrl=https%3A%2F%2Fcompany.jfrog.io%2Fcompany%2Fapi%2Fnpm%2Fregistry-name%2F%40scope%2Fpackage-name%2F-%2F%40scope%2Fpackage-name-1.0.0.tgz%23`,
+ expected: `npm:1.0.0`,
},
// https://github.com/yarnpkg/berry/pull/4702
{
version: `1.0.0`,
resolved: `https://packages.example.com/artifactory/api/npm/registry-name/@scope/package-name/-/@scope/package-name-1.0.0.tgz#eeeec1e4e8850bed0468f938292b06cda793bf34`,
- expected: `npm:1.0.0::__archiveUrl=https%3A%2F%2Fpackages.example.com%2Fartifactory%2Fapi%2Fnpm%2Fregistry-name%2F%40scope%2Fpackage-name%2F-%2F%40scope%2Fpackage-name-1.0.0.tgz%23`,
+ expected: `npm:1.0.0`,
},
// https://github.com/yarnpkg/berry/issues/902#issuecomment-732360991
{
Index: packages/yarnpkg-core/sources/LegacyMigrationResolver.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/packages/yarnpkg-core/sources/LegacyMigrationResolver.ts b/packages/yarnpkg-core/sources/LegacyMigrationResolver.ts
--- a/packages/yarnpkg-core/sources/LegacyMigrationResolver.ts (revision 3246d10cdcdcb6ffdb297e09a360a311c951396a)
+++ b/packages/yarnpkg-core/sources/LegacyMigrationResolver.ts (date 1671781469827)
@@ -19,7 +19,7 @@
// These ones come from the npm registry
// Note: /download/ is used by custom registries like Taobao
- [/^https?:\/\/[^/]+\/(?:[^/]+\/)*(?:@.+(?:\/|(?:%2f)))?([^/]+)\/(?:-|download)\/\1-[^/]+\.tgz(?:#|$)/, version => `npm:${version}`],
+ [/^https?:\/\/[^/]+\/(?:[^/]+\/)*(@.+(?:\/|(?:%2f)))?([^/]+)\/(?:-|download)\/(\1\2|\2)-[^/]+\.tgz(?:#|$)/, version => `npm:${version}`],
// The GitHub package registry uses a different style of URLs
[/^https:\/\/npm\.pkg\.github\.com\/download\/(?:@[^/]+)\/(?:[^/]+)\/(?:[^/]+)\/(?:[0-9a-f]+)(?:#|$)/, version => `npm:${version}`],
// FontAwesome too; what is it with these registries that made them think using a different url pattern was a good idea?
But as you see I had to change some existing assertions. (I can explain changes in regex, basically it's capturing @scope, and adding support if it's repeated in package name after /-/) Unfortunately I'm not familiar with codebase and cannot say if removing __archiveUrl is a good idea. Alternatively when debugging I spotted that https://github.com/yarnpkg/berry/blob/%40yarnpkg/cli/3.3.1/packages/plugin-npm/sources/NpmSemverResolver.ts#L19 this resolver returns false when passed range with __archiveUrl, which probably shouldn't happen reading https://github.com/yarnpkg/berry/blob/%40yarnpkg/cli/3.3.1/packages/plugin-npm/tests/NpmSemverResolver.test.ts#L7. However support there is only in getSatisfying, not in supportsDescriptor.
To reproduce
You need project with yarn@1, and dependency of following structure: https://github.com/yarnpkg/berry/blob/%40yarnpkg/core/3.3.1/packages/yarnpkg-core/tests/LegacyMigrationResolver.test.ts#L20
https://company.jfrog.io/company/api/npm/registry-name/@scope/package-name/-/@scope/package-name-1.0.0.tgz
^^^^^^ needs to be repeated
Environment
System:
OS: macOS 13.0
CPU: (10) arm64 Apple M1 Max
Binaries:
Node: 14.20.1
Yarn: 3.3.1
npm: 6.14.17
npmPackages:
jest: ^27.1.0 => 27.5.1
### Additional context
_No response_