Feature/xray 144147 onboard yarn v4

[gauriy-tech]

• The pull request is targeting the dev branch.
• The code has been validated to compile successfully by running go vet ./....
• The code has been formatted properly using go fmt ./....
• All static analysis checks passed.
• All tests have passed. If this feature is not already covered by the tests, new tests have been added.
• Updated the Contributing page / ReadMe page / CI Workflow files if needed.
• All changes are detailed at the description. if not already covered at JFrog Documentation, new documentation have been added.

What

Onboards Yarn V4 (Berry, native .yarnrc.yml mode) to jf curation-audit (jf ca),
and unifies Yarn V3 + V4 curation on a metadata-only lockfile resolution path.

Why / Design

jf ca must build a complete yarn.lock to enumerate the dependency graph, without
downloading 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 still
  fetches uncached tarballs to compute checksums, so a curation 403 on a blocked uncached
  package aborts before yarn.lock is written.
• Hosted plugin via yarn plugin import <url>: rejected — adds a runtime network
  dependency, breaks air-gapped CI.
• .yarnrc.yml flags (enableNetwork: false, etc.): rejected — doesn't produce a
  complete lockfile for uncached packages.
• Chosen: embedded resolution-only plugin (jfrog-yarn-resolve-lockfile.cjs, //go:embed).
  It calls project.resolveEverything() + project.persistLockfile() — resolving the full
  graph 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

• Yarn V4 native mode: registry + auth read from .yarnrc.yml (no jf yarn-config step).
• Non-invasive: all resolution happens in a temp copy; the only touch to the original project
  is bumping yarn.lock mtime so the next run can skip re-resolution.
• Full workspace coverage: attachWorkspaceMembersToRoot audits every workspace member's
  dependencies from the root, matching npm/pnpm.
• --run-native is a no-op for Yarn V4 (always native) with a deferred warning.
• V1 is rejected up front with an actionable message; V2 falls back to direct-dependency probing.

Tests

• TestRegisterYarnPluginInYarnrc, TestAttachWorkspaceMembersToRoot (yarn package)
• TestPromoteYarnWorkspaceMember incl. the $HOME-stop case (curation package)

---

---

[gineshkumar]

The warning text is V4-specific ("yarn V4 always resolves natively from .yarnrc.yml") but the guard tech == techutils.Yarn fires for V2 and V3 too.

Before this PR: --run-native on any Yarn project was a hard error from validateRunNativeForTech — clear signal to the user.
After this PR: V2/V3 users passing --run-native get a silent no-op with a message that references V4 and .yarnrc.yml, neither of which applies to their project.

Consider a version-agnostic message so users on V2/V3 aren't confused:

"--run-native has no effect for yarn; yarn curation always resolves natively from the Artifactory repository"

Or gate the V4-specific message on the detected version — the version is available in SetRepo at this call path.

[gineshkumar]

The six test cases here only exercise the GetProjectConfFilePath (yarn.yaml / npm.yaml) branches. The three new V4 native-mode code paths added in resolveNpmYarnTech have no positive test cases:

Path	Code	Missing test
Local .yarnrc.yml indicator	curationaudit.go:590	npm + .yarnrc.yml in working dir → promoted
Global ~/.yarnrc.yml	curationaudit.go:598-600	npm + .yarnrc.yml written to dummyHome → promoted
package-lock.json guard	curationaudit.go:586-588	npm + yarn indicator + package-lock.json present → NOT promoted

The test infrastructure already sets up dummyHome and tempProjectDir — all three cases fit naturally into the existing table. For example, the global ~/.yarnrc.yml case just needs:

{
    name: "npm, global ~/.yarnrc.yml only — promoted to yarn (V4 native mode)",
    tech: techutils.Npm.String(),
    // write .yarnrc.yml to dummyHome in the test body
    want: techutils.Yarn.String(),
},

[gineshkumar]

This function has zero unit test coverage. It determines whether V2 Yarn routes through /api/curation/audit/ vs the plain repo — getting it wrong would either misroute V3/V4 through the curation endpoint (which returns 403 HTML the plugin can't parse) or leave V2 off the endpoint silently.

The function is pure and the gofrog Compare inversion (>0 means receiver is less) makes the direction non-obvious. A small table-driven test would lock in the contract:

func TestShouldRouteThroughCurationEndpoint(t *testing.T) {
    assert.True(t,  shouldRouteThroughCurationEndpoint(version.NewVersion("2.5.0"), true),  "V2 + curation → route through endpoint")
    assert.False(t, shouldRouteThroughCurationEndpoint(version.NewVersion("3.0.0"), true),  "V3 → skip endpoint")
    assert.False(t, shouldRouteThroughCurationEndpoint(version.NewVersion("4.0.0"), true),  "V4 → skip endpoint")
    assert.False(t, shouldRouteThroughCurationEndpoint(version.NewVersion("2.5.0"), false), "non-curation → skip regardless of version")
}

[gineshkumar]

Suggestion: the docstring says 'yarn install --mode=update-lockfile' but after this PR that's no longer what runs. V3/V4 curation now uses yarn jfrog-yarn-resolve-lockfile (the embedded plugin); V2 runs a standard yarn install that fails at 403.

Consider updating to reflect the current behavior:

// ...and runs 'yarn jfrog-yarn-resolve-lockfile' (V3/V4) or 'yarn install' (V2) —
// so the customer's project content is never modified and read-only CI checkouts still work.