ci(release-please): Release please single PR

[d3xter666]

JIRA: CPOUI5FOUNDATION-1142

[d3xter666]

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

[matz3]

Please see my comment here: d3xter666#139 (comment)

[matz3]

Does this guarantee that the exact same transitive dependency versions from package-lock.json are used in the packages/cli/npm-shrinkwrap.json?

[d3xter666]

Thanks for challenging this!
Now, the answer is Yes!

I have reworked it, so that it:

1. runs npm ci for the monorepo -> Creates a package-lock.json
2. then isolates the cli out of the monorepo (npm shrinkwrap does not work properly for workspaces)
3. prunes unneeded dependencies from it
4. creates npm shrinkwrap for the isolated cli package
5. copies the generated npm-shrinkwrap.json back to the packages/cli
6. Deploys cli to npm

[matz3]

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:

1. 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).
2. 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 using 4.3.1, while currently our lockfile uses 4.3.0 . See:

   cli/package-lock.json

   Line 5829 in e0b185d

   "version": "4.3.0",

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.

[d3xter666]

Now the shrinkwrap generation is handled with an additional script.
In this situation it seems that extraction of npm-shrinkwarp.json from package-lock.json is the most convenient and stable solution.

[RandomByte]

For the shrinkwrap tool, I was wondering how we best integrate it in the monorepo. Maybe similar to the documentation as a dedicated package? Not sure whether lib/ is the best choice, since it's not really that important for the UI5/cli project.