test: make yarn tests agnostic of corepack defaults

[chadlwilson]

Description of Change

As noted in #8405 attempts to make tests agnostic of machine or npm-level corepack default yarn version.

The tests will fail currently if ones default corepack-yarn version is not Yarn Classic (v1). Setting the package manager makes this explicit; although the tests still rely on having a corepack-based yarn installation in order to switch between yarn versions.

Based on the comment below at #8413 (comment) they also fail if the dependency in the package.json happens to be in the local yarn cache, which we can fix by pointing to a non-existent dependency.

Related issues

• relates to fix: update docs #8405

Have test cases been added to cover the new functionality?

yes

[chadlwilson]

@jeremylong Perhaps you can try this PR locally.

If it's still not working, there is something else locally we're missing here:

• Are you using any kind of other version manager outside homebrew such that yarn / corepack / node versions might be coming from somewhere else when you run from the ODC clone dir (nvm, mise, aqua etc)?
• Perhaps double-check you dont have some uncommitted .yarnrc.yml, or version manager config or similar in local clone dir.
• What's your corepack version when run from ODC clone dir? corepack --version? Perhaps you have some really old corepack that is causing some problems.

[jeremylong]

For corepack I have:

$ corepack --version
0.29.4
$ where corepack
/Users/jeremy/.nvm/versions/node/v18.20.5/bin/corepack
/opt/homebrew/bin/corepack
$ ls -l /opt/homebrew/bin/corepack
lrwxr-xr-x  1 jeremy  admin  45 Dec 18  2024 /opt/homebrew/bin/corepack -> ../lib/node_modules/corepack/dist/corepack.js
$ ls -l /Users/jeremy/.nvm/versions/node/v18.20.5/bin/corepack
lrwxr-xr-x  1 jeremy  staff  45 Nov 11  2024 /Users/jeremy/.nvm/versions/node/v18.20.5/bin/corepack -> ../lib/node_modules/corepack/dist/corepack.js

[jeremylong]

I just re-ran this locally and received

[ERROR] Failures: 
[ERROR]   YarnAuditAnalyzerIT.testAnalyzePackageYarnClassicOnYarnBerryLockfile Unexpected exception type thrown, expected: <org.owasp.dependencycheck.analyzer.exception.AnalysisException> but was: <org.opentest4j.AssertionFailedError>    

[jeremylong]

Using some more of my free amp credits - we found the problem:

That's the root cause. Your ~/.yarnrc file contains a lastUpdateCheck entry, and more importantly, your local yarn has cached package metadata (from previous yarn install runs). When Yarn Classic runs yarn audit --offline, it uses its local cache to resolve mime-db@^1.52.0 → 1.52.0. With the cache, it successfully builds the Audit Request even though the Berry lockfile is unparseable. Without the cache (like on CI's fresh runner, or with HOME=/tmp/fakehome), it fails to resolve the dependency and never produces an "Audit Request" line — which is what the test expects.

So: the test is environment-dependent. It passes on CI because GitHub Actions runners have a clean $HOME with no yarn cache. It fails locally because your yarn cache allows Yarn Classic to resolve the package despite the Berry lockfile being unparseable. This is not about your yarn version — it's about local yarn cache state.

This is a fragile test. You might suggest to Chad that:

1. The test should use a dependency name that would never exist in anyone's yarn cache (e.g., a made-up package like @owasp-test/nonexistent-pkg)
2. Or the Berry lockfile fixture should be more obviously broken (e.g., completely invalid YAML) so it fails regardless of cache state

I ran yarn cache clean and the test started working locally. Thoughts on changing the dependency, per suggestion 1?

[chadlwilson]

Ahh ok, fair enough, yeah. Thank you Amp! I'll modify this PR. (edit: done)

I personally think the Yarn 1/Classic impl should be removed very soon anyway ( see #8423 - if you could express an opinion it'd be useful)

Yarn 1/Classic is seemingly completely EOL and even the --online CLI audit functionality will be permanently broken by end July (according to the rumours coming out of NPM support on the API removal). Our own impl will be permanently broken at that time for the same reason of the API going away.

[jeremylong]

LGTM