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
When building from our repo, often we are publishing multiple artefacts built from different package.json's, for instance publishing @types/mylibrary might be an additional artefact. Being able to define multiple runs of certain plugins gives greater control of the ci/cd pipeline.
With the move to ESM, and the changes in 28.x that have made the import cache even more difficult to find.
Both states of affairs make the very useful amanda-mitchell/semantic-release-npm-multiple plugin unusable. If a plugin can be declared multiple times with different config then there would be no need for the aforementioned plugin, which is not an ideal solution anyway as it involves reloading the require cache on each instance as a workaround due to the singleton nature of the plugins.
However looking through the semantic-release/npm plugin, there is very little in there apart from 2 booleans that mean that it is a true singleton, I cannot see a limitation to running this. However leafing through the documentation I have been unable to find any reference to what the expected outcome would be. Certainly support for this feature so it applies to all plugins would be infinitely more useful.
New feature description
Within the semantic release config be able to define the same plugin multiple times with different configuations.
Have the plugin run each time with it's own unique configuration.
New feature implementation
Move all singleton state out of the plugin, and defined within the instance.
If necessary adjust the runner.
Document with examples.
(Optionally) define a config lifecycle state that sets the config for semantic-release, and can be defined using customised plugins (possibly a separate feature)
The text was updated successfully, but these errors were encountered:
New feature motivation
When building from our repo, often we are publishing multiple artefacts built from different package.json's, for instance publishing @types/mylibrary might be an additional artefact. Being able to define multiple runs of certain plugins gives greater control of the ci/cd pipeline.
With the move to ESM, and the changes in 28.x that have made the import cache even more difficult to find.
Both states of affairs make the very useful amanda-mitchell/semantic-release-npm-multiple plugin unusable. If a plugin can be declared multiple times with different config then there would be no need for the aforementioned plugin, which is not an ideal solution anyway as it involves reloading the require cache on each instance as a workaround due to the singleton nature of the plugins.
However looking through the semantic-release/npm plugin, there is very little in there apart from 2 booleans that mean that it is a true singleton, I cannot see a limitation to running this. However leafing through the documentation I have been unable to find any reference to what the expected outcome would be. Certainly support for this feature so it applies to all plugins would be infinitely more useful.
New feature description
Within the semantic release config be able to define the same plugin multiple times with different configuations.
Have the plugin run each time with it's own unique configuration.
New feature implementation
Move all singleton state out of the plugin, and defined within the instance.
If necessary adjust the runner.
Document with examples.
(Optionally) define a config lifecycle state that sets the config for semantic-release, and can be defined using customised plugins (possibly a separate feature)
The text was updated successfully, but these errors were encountered: