[Bug?]: Can't use yarn v4 to run scripts without installing
Self-service
- [ ] I'd be willing to implement a fix
Describe the bug
I migrated my yarn v1 setup today to v4. Basically everything went really smooth, but I got a bit of trouble with my Dockerfile. When using yarn v1 I just did yarn start:prod and everything went smooth, but now I get the error: This package doesn't seem to be present in your lockfile; run "yarn install" to update the lockfile. I donβt quite understand why the lockfile would be required to just run a script, but when I added the lockfile and the .yarn folder to the final stage of the Dockerfiile I got the error: Usage Error: The project in /usr/src/app/package.json doesn't seem to have been installed - running an install there might help.
So my question now is: is this intended?. If not, how can I solve it?
And maybe some general feedback for the Dockerfile would be appreciated. I had a hard time finding good resources about setting it up in an efficient way.
To reproduce
# syntax=docker/dockerfile:1
ARG NODE_VERSION=20.11.0
FROM node:${NODE_VERSION}-alpine as base
# Set working directory for all build stages.
WORKDIR /usr/src/app
# Setup yarn modern
RUN corepack enable
################################################################################
# Create a stage for installing production dependecies.
FROM base as deps
COPY .yarn ./.yarn
# Download dependencies as a separate step to take advantage of Docker's caching.
# Leverage a cache mount to /root/.yarn to speed up subsequent builds.
# Leverage bind mounts to package.json, yarn.lock and .yarnrc.yml to avoid having to copy them
# into this layer.
RUN --mount=type=bind,source=package.json,target=package.json \
--mount=type=bind,source=yarn.lock,target=yarn.lock \
--mount=type=bind,source=.yarnrc.yml,target=.yarnrc.yml \
--mount=type=cache,target=/root/.yarn \
yarn workspaces focus --production
################################################################################
# Create a stage for building the application.
FROM deps as build
COPY .yarn ./.yarn
# Download additional development dependencies before building, as some projects require
# "devDependencies" to be installed to build.
RUN --mount=type=bind,source=package.json,target=package.json \
--mount=type=bind,source=yarn.lock,target=yarn.lock \
--mount=type=bind,source=.yarnrc.yml,target=.yarnrc.yml \
--mount=type=cache,target=/root/.yarn \
yarn install --immutable
# Copy the rest of the source files into the image.
COPY . .
# Run the build script.
RUN yarn run build
################################################################################
# Create a new stage to run the application with minimal runtime dependencies
# where the necessary files are copied from the build stage.
FROM base as final
# Use production node environment by default.
ENV NODE_ENV production
# Run the application as a non-root user.
USER node
# Copy package.json so that package manager commands can be used.
COPY package.json yarn.lock ./
COPY .yarn ./.yarn
# Copy the production dependencies from the deps stage and also
# the built application from the build stage into the image.
COPY --from=deps /usr/src/app/node_modules ./node_modules
COPY --from=build /usr/src/app/dist ./dist
# Expose the port that the application listens on.
EXPOSE 3000
# Run the application.
CMD yarn start:prod
Environment
System:
OS: macOS 14.4
CPU: (8) arm64 Apple M1
Binaries:
Node: 20.11.1 - /private/var/folders/q4/2gz37t6x53g2ptqmzkct86g40000gn/T/xfs-c07f2f58/node
Yarn: 4.1.1 - /private/var/folders/q4/2gz37t6x53g2ptqmzkct86g40000gn/T/xfs-c07f2f58/yarn
npm: 10.2.4 - ~/.nvm/versions/node/v20.11.1/bin/npm
npmPackages:
jest: ^29.5.0 => 29.7.0
Additional context
No response
looks like a duplicate of https://github.com/yarnpkg/berry/issues/2701 - Cannot run script without installing dependencies even if the script is trying to install
The COPY . . probably overwrote some install artifacts. Other than that, we would need a reproduction to tell.
yarn 4 doesnt create any node module folder , did you manage to fix this ?
Hi! π
It seems like this issue as been marked as probably resolved, or missing important information blocking its progression. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it.