-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide reproducible build by default #399
Comments
To be fair, running |
@aduh95 Thats true if you run the command in the Dockerfile but I think what @mcollina is pointing out is that the "newbie" should run that command locally and thus the package.json would be updated and make a reproducible build once |
How does this relates? The problem with node is to have in-tree dependencies (that causes cve chores) as well as constant updates of the latest version of said package manager. What I’m saying is that corepack should write down the packageManager field on first usage of a package manager loaded via corepack. This allows for future reproducible builds. (And possibly more chores for dependabot to keep this up to date). |
I thought you were referring to this feature, #364, since it would prevent "reproducibly" |
What if there is no package.json in the directory? |
The main concern is that Node.js should never, never, ever need an update for the end user to address a security vulnerability in one of the package managers installed by corepack. So having it install a locked version would not be acceptable, but having it record what it installed and re-using that would be ok assuming there was a way and it's well documented how the end user can force the version updatred to a newer version without having to update their Node.js version. |
Any chance you’d have an example of such Dockerfile that would be broken? To be sure we’re on the same page, as I’m not sure I understand what is the issue. |
I'm a little unsure whether this is Corepack's concern or individual package managers ... I don't know how I feel with potentially mutative operations on the Additionally, there's a risk of breakage for people using multiple package managers together (for instance someone running Overall I'm not opposed to this, but I feel like it shouldn't be a blocker for the initial release. It comes with risks, and I'd feel safer to have those risks to be spread over a separate major. Not everything needs to be lumped together - once we have the tool in place we're free to make other changes as needed, following traditional Node.js minor/major considerations. |
@aduh95 the example in the pnpm guide does not guarantee reproducible builds: https://pnpm.io/next/docker#example-1-build-a-bundle-in-a-docker-container. When Corepack will be enabled by default, the default usage of Node.js will create non-reproducible builds. I think this is critical to fix before enabling by default. FROM node:20-slim AS base
ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN corepack enable
COPY . /app
WORKDIR /app
FROM base AS prod-deps
RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install --prod --frozen-lockfile
FROM base AS build
RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install --frozen-lockfile
RUN pnpm run build
FROM base
COPY --from=prod-deps /app/node_modules /app/node_modules
COPY --from=build /app/dist /app/dist
EXPOSE 8000
CMD [ "pnpm", "start" ]
Agreed. Corepack is part of Node.js already. Marking it stable/enabling it by default is another matter, we are not talking about an initial release.
My 2 cents is that the risk of not reproducible builds by default is higher. If Corepack needs more time to figure it out, let's wait until it's ready. |
@mcollina the issue would manifest itself if pnpm were to release a new version between two execution of the Dockerfile, correct? Also, is my understanding correct that you are not suggesting that Corepack inside the Dockerfile to mutate the |
Yes. Specifically, if the
No. The packageManager field must be present before the image is built (but I guess this is what you meant). |
@arcanis a solution could be to have it as a requirement for a package manager to be handled by corepack. I'm not tied to a specific solution. I'm mostly concerned that a new major version of a package manager is not slipped into a docker image without me knowing, breaking my build. |
I like the idea of Corepack tracking This would be very similar to how a lockfile is written the first time you install and then subsequent installs read the lockfile. I do think we need to consider if there are cases where someone doesn't want this to happen. Probably the same people who don't like lockfiles will be the same people who don't want |
I share this pain very much. Not for newbies but also for any automation that it is critical for it to use the right command. Writing (off topic but only mentioning as I saw this tweet about stabilize requirements) Probably Other than auto, is there any hope that |
I'm still new to corepack but I would expect the following to happen if
On the next install it should then use the version as defined in the lockfile. And tools like Dependabot shall update the package manager version in the lockfile according to the allowed version range in the |
Corepack is writing data inside lockfiles? How does that even work with the various different lockfile formats out there? Before we have Corepack adding |
Yes, probably the other package managers won't like it if somebody else is modifying the lockfile content or is adding any kind of additional metadata. If you delete the package manager lockfile, you might also not expect that you just deleted the pinned package manager version too. Just wanted to say that, as a naive user, I'd expect that any version definition within |
There's no need for a lockfile here, the |
Corepack does not allow for reproducible builds by default. Consider a scenario where there is corepack enabled by default, i.e., the jump files are in place.
I run:
npm init -y
yarn
The result does not include a
packageManager
field in mypackage.json
.This makes the build non-reproducible for newbies as they do not know that they should run
corepack use yarn@4
.This is mostly a problem in Dockerfiles, because most newbies completely ignore the
corepack use
step.The text was updated successfully, but these errors were encountered: