pnpm-isolate-workspace icon indicating copy to clipboard operation
pnpm-isolate-workspace copied to clipboard

With pnpm 8, can't build with --frozen-lockfile anymore

Open kalvenschraut opened this issue 1 year ago • 5 comments

It would appear that pnpm 8 adds all peer dependencies to the dependencies section of the lock file causing a lockfile mismatch error.

I will try to resolve this issue

kalvenschraut avatar Apr 04 '23 22:04 kalvenschraut

Ended up hitting a wall.

If the peer dependency is listed as a dev dependency, than the peer dependency isn't listed as a prod dependency. Problem with this is that with the flags all dev dependencies are being stripped for me, so pnpm thinks all peer dependencies should be prod ones.

Gave up on that route, figured out out to use https://pnpm.io/cli/deploy and have a base container so I am no longer using this package. Can close this issue, or leave open not sure if my case will ever come up again

kalvenschraut avatar Apr 05 '23 03:04 kalvenschraut

@kalvenschraut Could you provide some details on how you use pnpm deploy to replace this package? For example it seems to me that pnpm deploy would need the full monorepo present in the docker image since for the deployed package it creates filesystem links back to the root of the monorepo for other monorepo packages that the deployed packge depends on.

jonaskello avatar Aug 28 '23 06:08 jonaskello

You can use a base image of the monorepo where all your packages are installed. Then all your app specific images use this base as an intermediate image. Runs deploy inside it and then copies over node_modules to the app image.

Since then I have actually swapped to using https://turbo.build/repo/docs/reference/command-line-reference/prune since I use turbo repo already, they didn't support pnpm at the time so I started using this package. Main reason being that building the base monorepo image was slower then using turborepo's prune. Also the image was pretty big since it held all the monorepo's dependencies.

kalvenschraut avatar Aug 28 '23 13:08 kalvenschraut

@kalvenschraut Thanks for taking the time to respond! I tried this (which is more or less the same as the docs example for pnpm deploy. I guess that is how you mean?

FROM node:18-alpine as pruned
COPY . /app
WORKDIR /app
RUN corepack enable
RUN pnpm pkg delete scripts.prepare
RUN pnpm --filter myapp-package --prod deploy pruned

FROM node:18-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=pruned /app/pruned .
ENTRYPOINT ["sh"]

The app has all code fully built in the current directory when the docker build starts. Something like this:

.
├── package.json
├── pnpm-lock.yaml
├── pnpm-workspace.yaml
├── packages
    ├── myapp
    ├── mypkg1
    └── mypkg2

The package myapp depends on the packages mypkg1 and mypkg2 which are also part of the monorepo. Once the docker image is created I end up with symlinks to other packages in the monorepo that are not resolved. So for example you would have this inside the built image:

/app # ls -lah node_modules/@myorg
total 8K     
drwxr-xr-x    2 root     root        4.0K Aug 29 05:45 .
drwxr-xr-x    8 root     root        4.0K Aug 29 05:45 ..
lrwxrwxrwx    1 root     root          32 Aug 29 05:45 mypkg1 -> ../../../packages/mypkg1
lrwxrwxrwx    1 root     root          32 Aug 29 05:45 mypkg2 -> ../../../packages/mypkg2

So there are symlinks to the packages that the deployed package depends on and they of course lead to nowhere becuase that part of the files were "pruned" away and not copied to the docker image. In order to make it work I need to also include the full root of the monorepo, not only the pruned directory created by deploy. This seems to defeat the purpose of pruning in the first place and leaves my confused :-).

jonaskello avatar Aug 29 '23 06:08 jonaskello

Have a look at isolate-package I think it does everything you need.

0x80 avatar Dec 17 '23 22:12 0x80