Issue with releasing pnpm sub project

[mtahir-cloudkitect]

I am creating a monorepo project which will have multiple typescript based sub projects. However when it tries to run the release pipeline on GitHub it successfully runs the 'release_github' job but fails on 'release_npm' job and throws the following error.

Run cd .repo && pnpm i --frozen-lockfile
  cd .repo && pnpm i --frozen-lockfile
  shell: /usr/bin/bash -e {0}
  env:
    PNPM_HOME: /home/runner/setup-pnpm/node_modules/.bin
 ERR_PNPM_NO_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is absent

Note that in CI environments this setting is true by default. If you still need to run install in such cases, use "pnpm install --no-frozen-lockfile"
Error: Process completed with exit code 1.

I can see that the only place I have pnpm-lock file is at the root level, however it is looking for the lock file in a subproject. So I am thinking of two solutions.

1. Create a pnpm lock file under sub-projects
2. Use the --no-frozen-lock file option when it runs 'Install Dependencies' job

I was trying to use second solution but I could not find a way to update those setting in the release_sub-project.yml through .projenrc file. Anyone else ran into similar issue? Any help will be appreciated.

[agdimech]

Hi,

I would strongly advise against using the --no-frozen-lock option in your CI environment as this can lead to non-deterministic installs. It's always safest to use a lockfile to ensure you get the same set of dependencies, no matter how many times you run the install.

Now in terms of your issue, can you not just perform a pnpm i --frozen-lockfile in the root directory first to install all your deps and then do your build and publication after that across all your packages?

[mtahir-cloudkitect]

That's what I thought, but it does not work, because it tries to look for lock file in the sub projects which it does not find, hence fails.

[agdimech]

Can you send me the script that you are executing? In general it should be something like:

1.) pnpm i --frozen-lockfile # from root dir
2.) npx nx run-many -t release # run the release target for each of your subprojects

Your release task should bump your version, build your code, unbump, pack your code. Then you can have seperate action steps to publish all your dists to npm or wherever. This is what we used to do in the PDK itself before we moved into a single distributable.

[mtahir-cloudkitect]

Thank you for the reply, I think option 2 is obviously the preferred route, but I have not been able to figure out how to make it work. I have this public repo created for the example

https://github.com/cloudkitect/pnpm-pdk-sample

When it tries to release the subprojects to npm it fails because it is executing the release logic at the root level, which does not have the dist folder with artifacts. So it fails.

When I put release: true flag on the subprojects it fails as well because now it can not find the pnpm-lock file in those subprojects. So it fails to release.

Here is what I am looking to achieve

release:true flag at the MonorepoTsProject level should create the necessary logic to release all the sub projects.

Is that possible out of the box? or do we need to create custom scripts? which would defeat the whole point of using pdk

[agdimech]

I'd say the easiest option here is to simply move all your built tgz into /dist/js/*.tgz. Then your release script will work as all distributables will be at the root. Easiest way to achieve this would be to add this before you synth your project in your .projenrc.ts:

project.subprojects
  .filter((p) => p instanceof AwsCdkConstructLibrary)
  .forEach((p) => {
    const distDir = `${path.relative(p.outdir, project.outdir)}/dist/js`;
    p.packageTask.exec(`mkdir -p ${distDir} && cp -r dist/js/*.tgz ${distDir}`);
  });

Once added re-run npx projen from the root to synth these changes and you should be good to go.

[mtahir-cloudkitect]

Unfortunately this does not work as expected, it does solve the problem of releasing to npm. But it always releases v0.0.0 since the release task was never executed on subprojects.