Hi there,

There was a change with how Railpack uses Node package managers in 0.0.70. It now will use the packageManager field of package.json to determine what package manager to use if it is specified. The problem you are seeing is because it was previously using npm, but it is now using pnpm and trying to install with a pnpm lockfile that doesn't exist. We should handle this better and I'll soon push an update to fix this. In the meantime, you can remove the packageManager field from the package.json file or add a pnpm lockfile. I'll report back when this has been fixed.

Thanks for the fast response! I think our use case is a little trickier as its a monorepo so wasn't using the rootDir by default. I have changed this over to build from the rootDir and it seems to be working better. We are experiencing issues using process.env in the code now too. Did the docker image change slightly during this upgrade? Just trying to understand why the variables were available before but seem to be acting slightly differently at runtime now

There should not of been any changes to the docker image or environment variables. Can you please link the effected deployment

https://railway.com/project/1d22fff6-ac81-4fb6-8567-1ab1604449ec/service/6fbdba9f-5123-433b-b958-5907b2c2cb17?environmentId=36be5574-0e15-4230-b45f-a27c54a8c3f3&id=c4b30d7f-4b41-4c2d-8786-f996976ec391 this is the deployment here - the application code itself hasn't changed since the last successful deployment. For context, process.env is being referenced in the constructor of a class. When Nest initialises it boots all the dependencies which results in the constructor erroring. Its obviously better to use nest/config rather than process.env but im curious as to what changed here. The error happens in the deploy logs (not build)

hmm nothing should of changed there. Let me take a deeper look

this one may be a better example for you https://railway.com/project/1d22fff6-ac81-4fb6-8567-1ab1604449ec/service/6fbdba9f-5123-433b-b958-5907b2c2cb17?environmentId=36be5574-0e15-4230-b45f-a27c54a8c3f3&id=f03e2d00-195d-49cb-8530-9668ce04da40 - I wonder if it has something to do with the monorepo again. We have changed from running inside apps/api to running from the / of the monorepo to ensure a pnpm-lock is set. Thats the only change I can think of that could potentially be related

The Railpack update would have no effect on the environment variables passed into the container when it starts, so I am really confused about what is happening.

Can you try setting the RAILPACK_INSTALL_CMD=npm i -g corepack@latest && corepack enable && corepack prepare --activate variable. This will use the same package manager behaviour that was being used in the previous version.

I've also just released a new version of Railpack that will not fail on the pnpm install command if there is no lockfile. So you can go back to how you setup the monorepo previously

Another thing to check would be to echo env in the start command. This will let you know what envs are available and indicate if it is an issue with the monorepo setup or if the envs are not correctly being provided.

Thanks for the new push of railpack. I reverted back to our old setup, added the install command to the variables and everything seems to be good now! Would it be helpful if I use this new railpack but point at the root of the monorepo to see if env variables get injected into the build correctly?

That could be helpful, but if it is working for you now then it is okay for you to leave it (not sure how much debugging you want to do on a Friday :p). It looks like it is an issue with changing where the root directory is where it will find different envs or not find them at all.