ci(release-please): Release please single PR #1176
Conversation
|
Please find a sample result of this flow in here: d3xter666#139 Note: Please ignore the title, it has been updated later in the config |
| with: | ||
| node-version: 24.x | ||
|
|
||
| - name: Install and publish ${{ matrix.package }} |
There was a problem hiding this comment.
Special handling for the CLI package is required, where the shrinkwrap needs to be updated/created after all dependencies have been released. Should this be done in a separate PR?
There was a problem hiding this comment.
Thanks!
I think we had something related to the shrinkwrap itself, but I can't find the discussion/BLI!
I have updated the action so that it:
- Runs the publishing of all the packages in a sequence. This ensures that during
npm cifor publishing for the next package in the chain, it will have the previous package already published on NPM. - For the CLI, it has a special step where all the packages are available already on NPM and it's been updated accordingly.
As per my research this is the approach many monorepos are wokring. Lerna, for example
|
Please see my comment here: d3xter666#139 (comment) |
.github/workflows/release-please.yml
Outdated
| run: | | ||
| echo "📦 Installing production dependencies for CLI" | ||
| npm ci --omit=dev | ||
| - name: Generate npm-shrinkwrap.json (prod only) |
There was a problem hiding this comment.
Does this guarantee that the exact same transitive dependency versions from package-lock.json are used in the packages/cli/npm-shrinkwrap.json?
There was a problem hiding this comment.
Thanks for challenging this!
Now, the answer is Yes!
I have reworked it, so that it:
- runs
npm cifor the monorepo -> Creates a package-lock.json - then isolates the cli out of the monorepo (
npm shrinkwrapdoes not work properly for workspaces) - prunes unneeded dependencies from it
- creates
npm shrinkwrapfor the isolated cli package - copies the generated
npm-shrinkwrap.jsonback to thepackages/cli - Deploys
clito npm
There was a problem hiding this comment.
I have tested this locally and compared the two lockfiles to see differences in package versions. Obviously they won't have the same content, but it helps to identify whether transitive dependencies are using the exact same version as in the existing package-lock.json. This is what I saw:
- The devDependencies are still included and would get installed by consumers (see https://github.com/UI5/linter/blob/01500503f8063ea9e639939ca6c515b332305580/.github/workflows/release-please.yml#L40-L54 for our current solution to this problem).
- I found at least one example where a transitive dependency uses a different (newer) version than defined in the
package-lock.json. For https://www.npmjs.com/package/ci-info the shrinkwrap was using4.3.1, while currently our lockfile uses4.3.0. See:Line 5829 in e0b185d
I'm very unhappy about the missing support from npm for such a scenario, but I don't see that we should use such a setup as it defeats the purpose of using a lockfile in the project. We will end up shipping a release with dependency version combinations that were never tested before. If there happens to be no solution to this problem, I would rather prefer to stop using a shrinkwrap, as it would at least allow consumers to upgrade the transitive packages on their end if issues occur. But not using a shrinkwrap for CLI packages is IMHO not a good idea at all and I would really like to continue using it.
JIRA: CPOUI5FOUNDATION-1142