Feature/xray 144147 onboard yarn v4#778
Open
gauriy-tech wants to merge 4 commits into
Open
Conversation
V4 operates in native mode: registry URL and auth token come from .yarnrc.yml (local or ~/.yarnrc.yml written by yarn config set --home) instead of requiring jf yarn-config / yarn.yaml. Key changes: yarn.go - Remove V4 rejection from verifyYarnVersionSupportedForCuration and configureYarnResolutionServerAndRunInstall (only V1 is now rejected). - resolveCurationLockfileDir: copy project to temp dir before running install (mirrors pnpm), so the customer's checkout is never modified. - For V4 curation: yarnCurationRegistry() rewrites api/npm/ → api/curation/audit/, then runYarnConfigSet sets a global npmAuthToken in the temp .yarnrc.yml so the rewritten URL authenticates correctly (the original token is scoped to api/npm/ and does not match the curation endpoint). - GetNativeYarnV4RegistryConfig: reads npmRegistryServer via yarn config get; reads npmAuthToken via direct YAML parsing of .yarnrc.yml and ~/.yarnrc.yml (yarn config get is unreliable for nested keys). - runYarnCommandQuiet: capture stdout+stderr on failure and emit as Debug log so failed-install diagnosis is visible. curationaudit.go - setRepoFromYarnrcForYarnV4: calls SetDepsRepo(repoName) in addition to setPackageManagerConfig. Both are required — PackageManagerConfig drives auth; SetDepsRepo populates params.DependenciesRepository so the curation endpoint URL is constructed in configureYarnResolutionServerAndRunInstall (was always "" before, causing the V4 branch to be skipped and the install to hit api/npm/ instead of api/curation/audit/). - resolveNpmYarnTech: detect V4 projects that have .yarnrc.yml (created by yarn set version 4) without a pre-existing yarn.lock, and projects using a global ~/.yarnrc.yml (--home setup); guard with package-lock.json absence to avoid npm misidentification. - validateRunNativeForTech: accept --run-native for Yarn as a no-op (V4 is always native; flag has no effect but should not error). - SetRepo: detect V4 via version check and route to setRepoFromYarnrcForYarnV4; make version-detection failures explicit errors instead of silent fallbacks. Co-authored-by: Cursor <cursoragent@cursor.com>
bd9988b to
0e05c1e
Compare
0e05c1e to
fd5de28
Compare
c5097ad to
ef1823e
Compare
ef1823e to
e29283f
Compare
ab03730 to
d07e8b3
Compare
d07e8b3 to
d615404
Compare
d615404 to
9fd40e0
Compare
9fd40e0 to
8981284
Compare
8981284 to
79d1ae5
Compare
79d1ae5 to
d9e1352
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
devbranch.go vet ./....go fmt ./....What
Onboards Yarn V4 (Berry, native
.yarnrc.ymlmode) tojf curation-audit(jf ca),and unifies Yarn V3 + V4 curation on a metadata-only lockfile resolution path.
Why / Design
jf camust build a completeyarn.lockto enumerate the dependency graph, withoutdownloading tarballs (curation blocks blocked tarballs with a 403, which aborts a normal
install before the lockfile is written).
Approaches considered:
yarn install --mode=update-lockfile(previous V3 behavior): rejected — it stillfetches uncached tarballs to compute checksums, so a curation 403 on a blocked uncached
package aborts before
yarn.lockis written.yarn plugin import <url>: rejected — adds a runtime networkdependency, breaks air-gapped CI.
.yarnrc.ymlflags (enableNetwork: false, etc.): rejected — doesn't produce acomplete lockfile for uncached packages.
jfrog-yarn-resolve-lockfile.cjs,//go:embed).It calls
project.resolveEverything()+project.persistLockfile()— resolving the fullgraph from registry metadata only (no tarball fetch), so blocked packages never abort
the lockfile. The plugin is written into the per-run temp dir, never the customer's project.
V3 behavior change (intentional): V3 curation previously used
--mode=update-lockfile;it now uses the same embedded plugin as V4. V3 had the identical tarball-fetch abort problem,
so this gives V3 strictly better behavior and keeps V3/V4 on one code path.
Highlights
.yarnrc.yml(nojf yarn-configstep).is bumping
yarn.lockmtime so the next run can skip re-resolution.attachWorkspaceMembersToRootaudits every workspace member'sdependencies from the root, matching npm/pnpm.
--run-nativeis a no-op for Yarn V4 (always native) with a deferred warning.Tests
TestRegisterYarnPluginInYarnrc,TestAttachWorkspaceMembersToRoot(yarn package)TestPromoteYarnWorkspaceMemberincl. the$HOME-stop case (curation package)