fix: update docs

[jeremylong]

• updates gradle example to use the current dependency version
• comments out a test case that is failing locally related to yarn

[jeremylong]

I was preparing for a release and had an issue with the test case. I'm not sure why it is working in our CI and not locally... So I commented it out for now.

[chadlwilson]

What's the error message the test gives? I improved the error messages last time so it should say what's wrong. If you have Yarn 1 installed locally but not Yarn Berry or vice versa (but not corepack) then you can't run all the tests, because it should be trying to verify that the analyzer can switch versions dynamically.

Probably better to just skip the tests locally when preparing release?

The old code just silently skipped tests when pre-requisites weren't available, which is really bad practice. But there needs to be a better way to handle these tests with pre-requisites.

[jeremylong]

@chadlwilson the error I am seeing makes it seem like the analyzer "works" but detects zero dependencies:

[ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.938 s <<< FAILURE! -- in org.owasp.dependencycheck.analyzer.YarnAuditAnalyzerIT$Classic
[ERROR] org.owasp.dependencycheck.analyzer.YarnAuditAnalyzerIT.testAnalyzePackageYarnClassicOnYarnBerryLockfile -- Time elapsed: 1.063 s <<< FAILURE!
org.opentest4j.AssertionFailedError: Unexpected exception type thrown, expected: <org.owasp.dependencycheck.analyzer.exception.AnalysisException> but was: <org.opentest4j.AssertionFailedError>
        at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
        at org.junit.jupiter.api.AssertThrows.assertThrows(AssertThrows.java:67)
        at org.junit.jupiter.api.AssertThrows.assertThrows(AssertThrows.java:35)
        at org.junit.jupiter.api.Assertions.assertThrows(Assertions.java:3128)
        at org.owasp.dependencycheck.analyzer.YarnAuditAnalyzerIT$Classic.testAnalyzePackageYarnClassicOnYarnBerryLockfile(YarnAuditAnalyzerIT.java:69)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
Caused by: org.opentest4j.AssertionFailedError: More than 0 dependencies should be identified ==> expected: <true> but was: <false>
        at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
        at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
        at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
        at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
        at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:214)
        at org.owasp.dependencycheck.analyzer.YarnAuditAnalyzerIT.testAnalyzeForMimeDb(YarnAuditAnalyzerIT.java:119)
        at org.owasp.dependencycheck.analyzer.YarnAuditAnalyzerIT$Classic.lambda$testAnalyzePackageYarnClassicOnYarnBerryLockfile$0(YarnAuditAnalyzerIT.java:69)
        at org.junit.jupiter.api.AssertThrows.assertThrows(AssertThrows.java:53)
        ... 7 more

[chadlwilson]

testAnalyzeForMimeDb

Is the error the same on the original test? That seems to be using new code you have added (testAnalyzeForMimeDb) rather than the standard uglify-js dependencies all the others use.

What does it log starting with Analyzing using Yarn for detecting the yarn version? My guess is it's saying Yarn berry.

My guess is that due to however your "default" Yarn is installed, it is actually running with Yarn Berry (2+) as the fallback/default version, which is why it is not throwing an exception. Currently the test relies on Yarn 1.x being the default version on the path - as happens with corepack-installed Yarn without special config.

But I wouldn't expect testAnalyzePackageYarnClassic to be passing if that is the case.

In any case, can you perhaps try with

Subject: [PATCH] force Yarn 1.x on tests even if default local-installed Yarn is 2+
---
Index: core/src/test/resources/yarn/yarn-classic-audit-bad-berry-lockfile/package.json
===================================================================
diff --git a/core/src/test/resources/yarn/yarn-classic-audit-bad-berry-lockfile/package.json b/core/src/test/resources/yarn/yarn-classic-audit-bad-berry-lockfile/package.json
--- a/core/src/test/resources/yarn/yarn-classic-audit-bad-berry-lockfile/package.json	(revision c548d8cfc4f0315e2aa08df58a2bfa6f31cfab6d)
+++ b/core/src/test/resources/yarn/yarn-classic-audit-bad-berry-lockfile/package.json	(date 1775706055123)
@@ -14,5 +14,6 @@
     "precommit": "grunt precommit"
   },
   "repository": "https://github.com/OWASP/NodejsGoat",
-  "license": "Apache 2.0"
+  "license": "Apache 2.0",
+  "packageManager": "yarn@1.22.22"
 }
Index: core/src/test/resources/yarn/yarn-classic-audit/package.json
===================================================================
diff --git a/core/src/test/resources/yarn/yarn-classic-audit/package.json b/core/src/test/resources/yarn/yarn-classic-audit/package.json
--- a/core/src/test/resources/yarn/yarn-classic-audit/package.json	(revision c548d8cfc4f0315e2aa08df58a2bfa6f31cfab6d)
+++ b/core/src/test/resources/yarn/yarn-classic-audit/package.json	(date 1775706128039)
@@ -57,5 +57,6 @@
     "zaproxy": "^0.2.0"
   },
   "repository": "https://github.com/OWASP/NodejsGoat",
-  "license": "Apache 2.0"
+  "license": "Apache 2.0",
+  "packageManager": "yarn@1.22.22"
 }

IIRC Yarn Classic/1.x installed standalone will just ignore these fields as it doesn't understand them; so it'd continue to work. If corepack or Yarn 2.x is installed, it should be smart enough to switch version as intended - or to "fail fast" and more clearly with a message about the yarn version not matching package.json.

[jeremylong]

Pretty sure the test is trying to show that the analysis fails - so fixing the package.json isn't the solution for this. I removed the test method I erroneously created. However, I have left the test as @Disabled as it is still broken on my end. Basically, my version of yarn is not failing when called - it just returns zero dependencies.

$ ls -la /opt/homebrew/bin/yarn
lrwxr-xr-x  1 jeremy  admin  41 Dec 18  2024 /opt/homebrew/bin/yarn -> ../lib/node_modules/corepack/dist/yarn.js
$ yarn --version
1.22.22

[chadlwilson]

I wrote the test, and fixed the earlier error handling that was there, and know corepack and yarn in reasonable detail, so I assure you I know what the test is intended to do and how it works. :)

The most important bit is still what version it detects for “Analyzing using Yarn” when running the test.

It should not even be getting as far as actually completing the analysis, because yarn v1 cannot understand such lock files, and this is the error handling it is trying to test. So I suspect it’s not actually using yarn v1 at runtime.

The yarn Analyzer auto switches analysis logic to apply based on determining the yarn version for a given package.json, right. In corepack-aware environments, yarn versions need to be dynamically determined by trying to execute yarn in a given working directory - since running yarn —version in one dir can yield a different result to another, because corepacked yarn can bootstrap different yarn versions dynamically as dictated by package.json.

The test setup currently does not specify any yarn version in the package.json, which is probably not correct, so it is implicitly assuming that the “default” or fallback yarn is v1 - but that’s not universally true - you can use corepack to change the default yarn version. My suggested patch to the package.json is being explicit about which yarn version it expects the test to run with so it can simulate error handling for cases where yarn v1 is run on yarn v2+ lock files, without relying on any environment defaults. Otherwise any node version manager (or similar) tool can also be interfering with the available corepack/yarn version, and it is possible t9 switch defaults.

Anyway, now I broadly know your environment (looks like homebrew yarn - which should be corepack yarn) I can see if I can replicate to “simulate” the error handling. I’ll submit a PR and you can try it locally, but it’ll still be a guess unless you can share what is logged during the test run to confirm the “dynamically determined” yarn version.