You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Providing a context to the plugins would be useful to reduce code duplicates and maintainability of the plugins itself.
motivation
I'm currently writing a hook plugin which automates the distribution of release assets and publishing packages. That requires some information which are currently only available in the root config (which plugins by default have no access to) and initializing clients for github/gitlab myself. This produces alot of "duplicate" code (since the config and providers are initialized by semantic-release before) and is somehow a bit error prone.
In order to make it easier for plugins to access resources which are already initialized by semantic-release a context should be passed to the plugin. I would suggest the context should provide the following resources to the plugin:
root config (to access options which are out of the plugin scope)
plugin manager or list of plugins (to check if dependant plugins are installed)
considerations
which plugins would benefit of such context (I assume it is only relevant to hook plugins)
how to pass the context to the plugin (obviously it would be needed at the Init but is there a nice way to add the context and maybe keep backwards compatibility ?)
I would be happy to implement this feature but beforehands I want to know if it would be integrated and need to have the considerations answered.
The text was updated successfully, but these errors were encountered:
Providing a context to the plugins would be useful to reduce code duplicates and maintainability of the plugins itself.
motivation
I'm currently writing a hook plugin which automates the distribution of release assets and publishing packages. That requires some information which are currently only available in the root config (which plugins by default have no access to) and initializing clients for github/gitlab myself. This produces alot of "duplicate" code (since the config and providers are initialized by semantic-release before) and is somehow a bit error prone.
(You can take a look into https://github.com/superewald/semantic-release-hooks-distributor for reference, it's not finished but shows clearly why a context would be useful)
proposal
In order to make it easier for plugins to access resources which are already initialized by semantic-release a context should be passed to the plugin. I would suggest the context should provide the following resources to the plugin:
semantic-release/cmd/semantic-release/main.go
Line 85 in c2f6a17
semantic-release/cmd/semantic-release/main.go
Line 129 in c2f6a17
considerations
Init
but is there a nice way to add the context and maybe keep backwards compatibility ?)I would be happy to implement this feature but beforehands I want to know if it would be integrated and need to have the considerations answered.
The text was updated successfully, but these errors were encountered: