Propagate args to pnpm install command via pnpm sst upgrade

[BSteffaniak]

Hi, by default pnpm install when ran in CI environments prevents the lock file from being out of sync with the package.json file. This makes pnpm sst upgrade impossible to run in CI via pnpm. (I try to do this to auto upgrade the SST version nightly.) They allow passing a --no-frozen-lockfile argument to the pnpm install command to overcome this.

I couldn't find any other environment variable override to fix it and I think it might be detecting the CI-ness of it because it is installed via a github action, but I am just speculating... I dug through the code but it seems a little too gnarly/unfamiliar for me to find the root cause of it in a quick look through.

However, regardless of whether there would be a fix outside of argument propagation, I think it might be worthwhile to implement argument propagation to the install commands (pnpm, npm, yarn, bun) around here.

Thoughts?

I'd be happy to take a stab at it, but not sure if you guys have other ideas around it.

[thdxr]

is there a reason you're running sst upgrade in ci? it's meant as a simple convenience thing to update your package.json - there are better ways to do this if you need more control

[BSteffaniak]

I have github workflows that run on a schedule to auto-upgrade dependencies for various projects.

What are the better ways to do the upgrade?

[BSteffaniak]

I guess I could update the package.json to use ^version instead of locking it down to an explicit version. That way a normal pnpm update would update the version. And since ion doesn't have any other cdk related packages that are required to stay in sync, I wouldn't have to worry about those versions causing problems.

I'm still curious about other potential better ways to handle this. I realize upgrading deps in CI might be a little backwards.

[jayair]

Yeah I think that might be a better way. The sst upgrade like Dax was saying is more of a helper.

[BSteffaniak]

Ok, that's reasonable. Thanks!