feat: add additional_packages input variable

[codfish]

Allows users to install non-standard plugins and shareable configuration packages for use in their plugins and extends without having the install those dependencies in their own applications.

Closes #168

Related Issue

#168

[MrSwitch]

Thanks @codfish. If we need to explicitly define the packages to install then arguably isn't an npm install step a more intuitive approach?

i.e....

- name: Install extra dependencies
  run: npm i --no-save @semantic-release/apm@3.0.0 @semantic-release/git @semantic-release/apm-config
- name: semantic-release
  uses: codfish/semantic-release-action@additional-packages
  with:
    extends: '@semantic-release/apm-config'
    plugins: |
      ['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/github', '@semantic-release/apm', '@semantic-release/git']

[codfish]

@MrSwitch thanks for the review. Nothing stopping you from doing that today. If we come to the conclusion that this doesn't really provide any value I'm fine scraping it. I want to make sure any added functionality is providing real value to users. That being said, I'm also very open to iterating and finding a solution that does help simplify things.

Btw, sorry, I totally meant to respond to your original thoughts on the issue yesterday, but forgot to mention it. I can see the benefit of possibly pre-installing official plugins but my hesitations are around the overhead & unforeseen issues I may run into with maintaining that. This action was meant to be similar to running npx semantic-release in a way, with the added benefit of the direct integration of GitHub Actions, i.e. setting outputs, etc. It's also actually faster with the action if you use the docker image.

I just don't know what weird compatibility issues I might see with maintaining all different versions of those dependencies, keeping those up to date, adding new versions or plugins as they are released, etc. I would rather leave that complexity on the user-side, like semantic-release does today. I'm not totally sold either way though, so I'll keep the issue open ended.

In terms of this change then, do you see any benefit to doing this? If it's current implementation is not ideal in your opinion, is there a way you think it could be improved?

For instance, what if we auto-installed dependencies based on what's specified in plugins and extends? I see flaws in this approach, i.e. redundant if you've already got those deps installed, but still might be more straightforward, no new custom options involved then. Or maybe it's even more confusing...?

[MrSwitch]

For instance, what if we auto-installed dependencies based on what's specified in plugins and extends? I see flaws in this approach, i.e. redundant if you've already got those deps installed, but still might be more straightforward, no new custom options involved then. Or maybe it's even more confusing...?

I was thinking along these same lines. I certainly agree locking down a version of any dependencies is the wrong thing to do. As such I retract my comment, and what you have before is best all around. As i now feel that running a step npm i --no-save @semantic-release/plugin,... is my preferred choice, and let's me maintain versioning etc...

What I think you have in this github-action is a really good tool. To elaborate on how i intend to use it is to abstract all the things semantic-release does well, tagging and publishing, to a single config. And have package.json's dependencies/devDependencies exclusively focused on the projects development requirements.

Thanks for replying to the original ticket, i know it's a hard slog maintaining open source projects and i thankyou so much for giving this your time. 🙏

[codfish]

@MrSwitch much appreciated, that's for contributing your time and thoughts!

[github-actions]

🎉 This PR is included in version 1.10.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀