Modify release pipeline to install dependencies in a workflow directly and not through package.json

[derberg]

Reason/Context

Comes from asyncapi/generator#801

tl;dr

Installation of semantic-release and other release dependencies on a CI level is already practiced in our Go projects and works like a charm. Just have a look at:

• https://github.com/asyncapi/parser-go/blob/master/.github/workflows/.releaserc - release config do not have to be in package.json and can be a separate file, inside .github/workflows directory, so we can replicate it automatically as other workflow files in all repos.
• https://github.com/asyncapi/parser-go/blob/master/.github/workflows/release.yml#L51 - since few releases of semantic-release, dependencies that we now explicitly add as a dependence (like @semantic-release/github ) are actually included in semantic-release. So we only need to explicitly install only conventional-changelog-conventionalcommits
• https://github.com/asyncapi/parser-go/blob/master/.github/workflows/release.yml#L61) - we do not really even have to install semantic-release as a dependency but just use npx like npx semantic-release (just locking to specific version)

there is one thing I will have to test before I proceed is, what if there is a repo that will get new config but already has some dependencies in place and also a release config in package.json. For sure dependencies used in a CI will be used instead of those installed with package.json but what about the config of the release, which one is first, .releaserc or package.json - that I do not know yet

Description

What I do with this task is:

• introduce global release config for all. It will be replicated to all repos using topics_to_include: common-release.
  • I will add new topic to all repos that have release property in package.json, unless I know that like in case parser-js release steps are a bit custom
  • I will not modify package.json (remove release prop) for the repos that will start using global .releaserc. It is just to much effort. This should be done by maintainers at some point of time. Maybe I will find some time to run a script that in all these repos will create a good first issue issue to modify package.json
• modify current nodejs related release pipeline:
  • I will make sure we install only conventional-changelog-conventionalcommits with specific version, and run npx semantic-release (of specific version) instead of npm run release that calls semantic-release
  • I will not modify package.json (remove release script). It is just too much effort. This should be done by maintainers at some point of time. Maybe I will find some time to run a script that in all these repos will create a good first issue issue to modify package.json

This is not a mandatory change. If you are a maintainer of Node.js project and you hate this new approach, just please lemme know in a comment to not add common-release topic to your repository. Just keep in mind that because of it, once this PR is merged, you will no longer receive updates to release pipeline and you will have to mange it separately

[derberg]

@asyncapi/tsc_members

Pinging you for important visibility. Please have a look at above change. It is not mandatory, but you need to let me know you do not need it, as by default I will include all Node.js projects.

Even if you agree with the change, you still need to be aware that most probably (95% a chance) I will create a follow-up issue in your repo that explains what changes you have to make in your package.json later, so it is not confusing for you and contributors that there are 2 separate release configurations in the repo

[derberg]

ok, trying things out in asyncapi/generator#815

[derberg]

ok, it was smooth -> asyncapi/generator#815

after suggested changes to generator, release worked like a charm

[derberg]

semantic-release uses https://github.com/davidtheclark/cosmiconfig for loading configurations, and according to their docs, unfortunately first priority is package.json and later dedicated files 😞 so this issue cannot be solved in an easy way that we push new config files and new release setup and that cleanup of package.json can be done later by different contributors.