fix: add corepack to docker image

[dcyrille18]

Description of Change

This merge request adds Corepack to the base OWASP Dependency-Check Docker image.
The goal is to provide native support for package managers such as Yarn and pnpm without requiring downstream images or CI pipelines to manually install Corepack.

This change enables:

• Use of yarn install or pnpm install directly inside the owasp/dependency-check image
• Better compatibility for projects using modern Node.js tooling
• Reduced setup time in CI where Dependency-Check is executed alongside Node-based dependency workflows

No breaking changes are introduced:
If Node.js tooling is not needed, the image behaves exactly as before.
Corepack remains disabled until explicitly invoked (e.g., corepack enable), following Node.js conventions.

[chadlwilson]

It's likely not correct to leave pnpm there.if installing corepack.

[dcyrille18]

Depending on the user project configuration, the analyzers could use pnpm or corepack, no ?

[chadlwilson]

corepack is a way to install/run pnpm (and yarn) - optionally with locked versions. When you install both you likely make a mess of the PATH.

We shouldn't have multiple ways to do the same thing in a container image, and in my view nor should it be a bag of different tools/approaches that various people like to bootstrap their tools.

We should pick one approach that we think is best for most users.

[dcyrille18]

So perhaps we can just install directly the latest NodeJS LTS and let corepack configure theirs environments (yarn, npn, pnpm) ?

[chadlwilson]

Maybe - npm -> corepack -> yarn | pnpm

No choice if we want to use corepack , since corepack isn't bundled with Node on Alpine, as you showed earlier.

But we might want to pre-cache a version for those not using package manager directive so it's not dynamically downloading in every single case (which is not easy to decide).

And need to actually research and see where pnpm and yarn are going now that corepack is no longer distributed with NodeJS. If they are ditching corepack and won't recommend use with it there's no point adding it here and we'll just be storing up problems for later.

[dcyrille18]

It seems corepack is no more distributed by the NodeJS from >25 but already recommended to manage properly the packages managers.

[chadlwilson]

Corepack remains disabled until explicitly invoked (e.g., corepack enable), following Node.js conventions.

This description looks LLM generated, because it mKes.assertions about the change that are already already true before the change, but i don't believe this particular point is actually correct.

Did you test this before/after?

When you install the package globally, from memory im pretty sure the shims are all crested per the package.json and on the path. IIRC corepack enable is just for the node-prepackaged version. If that were the case this change wouldn't be needed as corepack is already bundled with Node < 25 and should already be there ready to be enabled.

I'll have another look later, but this looks messy to me, given yarn and pnpm are still being manually installed. Should probably use only one 9r the other install approach - not both.

[dcyrille18]

This description looks LLM generated, because it mKes.assertions about the change that are already already true before the change, but i don't believe this particular point is actually correct.

Well seen, I ask to copilot to help me to write this change description because we turn around since many hours on how to get owasp working with our NodeJS project using yarn berry and corepack.

Did you test this before/after?

Yes, of course, I tested and I thought it works but after more tests, it seems not totally in this first try. Let me add a short description on what we have before:

/src $ yarn --version
1.22.22
/src $ yarn
error This project's package.json defines "packageManager": "yarn@4.13.0". However the current global version of Yarn is 1.22.22.

Presence of the "packageManager" field indicates that the project is meant to be used with Corepack, a tool included by default with all official Node.js distributions starting from 16.9 and 14.19.
Corepack must currently be enabled by running corepack enable in your terminal. For more information, check out https://yarnpkg.com/corepack.
/src $ corepack
/bin/sh: corepack: not found

And after the first MR try (not fully automated for CI/CD):

/src $ yarn --version
! Corepack is about to download https://repo.yarnpkg.com/4.13.0/packages/yarnpkg-cli/bin/yarn.js
? Do you want to continue? [Y/n] y

4.13.0

After further test, it seems that adding the environnement variable COREPACK_ENABLE_DOWNLOAD_PROMPT=false make the yarn version download totally transparent:

/src $ yarn --version
4.13.0

[chadlwilson]

In my opinion if we're going to do this we should probably switch the whole image to use corepack and only corepack. I'm not sure if there is value in both, and probably only downsides.

I guess corepack isn't there currently because the image is installing npm directly; not node.

[dcyrille18]

Update done as requested with prepached images for yarn (v1) and pnpm (latest):

Current:

/src $ pnpm --version
10.27.0
/src $ yarn --version
1.22.22

After MR:

/src $ pnpm --version
10.33.0
/src $ yarn --version
1.22.22

This build will now allow users to install custom package managers if needed.

[marcelstoer]

I do not support this proposal. Specific extensions should be handled in downstream images that extend from ours.

[chadlwilson]

I do not support this proposal. Specific extensions should be handled in downstream images that extend from ours.

Not sure how familiar you are with the node/npm ecosystem but it’s a bit more complex than “specific extensions” in my view. We already pre-package node, npm, yarn and pnpm using disparate approaches. The ODC code for these analyzers is already “corepack compatible/aware”.

For many years (prior to Node 25) corepack was pre-distributed with all Node versions (like with npm) and for all of these alternate package managers was the recommended approach to either bootstrap or install them, and provide a mechanism to “lock” ones version manager for reproducibility. Corepack shimmed the entry point scripts and would look at the packageManager field of the adjacent package.json, look for a config and determine whether it could run a locked version from its cache, already in source control or downloadable on-the-fly, plus verifying shas etc.

In other words, prior to Node 25, one could consider corepack being installed and enabled to be a sensible default for a “Swiss army knife” image like this which already pre-packages all sorts of tools. For some reason node voted not to package it anymore, which adds friction for every single alternate package manager. It’s worth noting that this change will not graduate to LTS until April/May 2027 so for now, corepack is still “LTS”ish.

According to OP, there appears to be a gap in the ODC image at the moment that causes yarn and pnpm to not work in a corepack aware way, and our image was possibly not “caught up” when the Yarn 2+ support was finally fixed in ODC itself. I think we need to confirm what these problems are. This is important now because yarn/pnpm are directly invoked by ODC and failure to use the correct version implied by package.json will cause scanning failures.

It’s likely only an accidental side effect of Alpine’s non-standard packaging process for node/npm that corepack has not been included earlier. Most distros follow nodes official packaging and include it. Some other distros also split corepack from node, but they include a proper package for it, so you’re not installing into the npm global space (Arch, Wolfi, newer Debian). For some reason Alpine has no distinct corepack package, however provides corepack in a compliant way with the nodejs-current packages -however these current versions are not locked to lts and are otherwise unsuitable.

Now, to summarise my earlier messages, the messy bit is determining how to move forward and requires some research into whether pnpm, yarn and others will continue to recommend corepack. It doesn’t make sense for us to add it if everyone is moving away.

In retrospect it’d probably have been better to open an issue to discuss the problem before submitting a solution, but it’s not the end of the world, as there’s not too much effort here I think.

In my personal view, if corepack still has a role, rather than using npm global space, I would suggest

• moving away from Alpine towards Wolfi
  • which is similarly a minimal security focused rolling undistro, but is glibc+based
  • with fewer breaking changes than Alpine, with much higher volume throughput on packaging
  • supports patching old versions of packages without abandoning like Alpine does
  • Also uses apk, with most packages named consistently with Alpine, making migration path easy for child packages
• install corepack package in place of npm/yarn/pnpm

But I think we need to figure out exactly which combinations are not working right now with the pre-installed versions and whether corepack still has a role - before we decide to do anything.

[marcelstoer]

👍 Thanks for the effort that went into this write-up! Much appreciated.

[chadlwilson]

Yeah, sorry for the novel.

I am interested in finding a consistent way forward as I recently ended up using corepack in the build to ensure we can run tests reliably since right now most of such integration/functional tests are coded to “don’t run test if yarn/pnpm etc not found” which is basically useless in ensuring we don’t break functionality since tests won’t even run if we set up the build incorrectly.

DependencyCheck/.github/workflows/build.yml

Line 65 in bc07974

- run: npm install -g corepack && corepack enable

I used corepack for simplicity so I could start ensuring these tests actually have a version of yarn to run, but will change the approach for consistency with whatever we choose for docker, if it makes sense to do so.