Custom Plugins: Documentation is unclear on location and usage of custom plugins

[airtonix]

Existing documentation for plugins looks like:

https://github.com/googleapis/release-please/blob/3bae6137f939a4db2df1d32436453d1ac2a41e9f/docs/manifest-releaser.md#plugin-usage

To use a plugin in your manifest based release-please setup, simply add it to the array of the "plugins" key in your release-please-config.json. (Note: the plugin must already be implemented, see below)

What does the plugin must already be implemented ?

a) must exist in the release-please repo as google sanctioned code? or
b) can be a valid nodejs import string?

Ideally it should just be b) so i can do :

{
  "plugins": [
    {
      "type": "@my-monorepo/release-please-nx-workspace"
    }
  ]
}

This has useful benefit:

• some plugins are going to need constant updating, for example an nxdev workspace plugin that needs to be part of the release-please repo would need constant updating to stay relevant with the latest version of nxdev.
• some plugins will probably involve the use of non publishable internal business logic
• it will make testing new ideas faster without having to deal with the release-please repo itself.

[airtonix]

Looks like someone else has provided some answers to this by way of creating an external plugin:

https://github.com/ipfs-shipyard/release-please-ipfs-plugin#readme

Add to release-please config

{
  // ...
  "plugins": [/** ... */, "@ipfs-shipyard/release-please-ipfs-plugin"]
  // ...
}

Ensure you call the release-please binary

[!NOTE]
Simply adding to the release-please config is not enough to make it run. You must also call the release-please CLI with the plugin name.

release-please release-pr ... --plugin=@ipfs-shipyard/release-please-ipfs-plugin

This is the only way I found that a release-please plugin can actually load itself, so it can call registerPlugin, so that the inner pluginFactories can reference it when running.