Cannot override assets about git HOT 12 CLOSED

Which version of this plugin and semantic-release are you using?

from git.

hey @pvdlg
semantic-release/git @ 7.0.5
semantic-release @ 15.12.4

from git.

Are you sure it [email protected]? Is it confirmed by the first line of log?

from git.

Ah nevermind. You are configuring the assets option in the declaration in plugins. But you overwrite that with the prepare declaration.

Please read carefully the plugins configuration doc. The properties verifyConditions, prepare, etc... are not required anymore.

from git.

Thank you! This helped me a lot!
I actually thought, that the fields are useful by providing the explicit flow. And "publish": [], works, so I'd never get to the point that plugin settings should be set up in every point of use.

Probably it would be good to update the documentation on that topic.

from git.

What doc would you change? I don't see the individual steps being mentioned anywhere.

from git.

Alright. All I want to say is that the behaviour is not really expected. If you can improve developer experience in the future, it will be awesome!
Thanks for the help!

from git.

The plugins option allow you to define which plugins to use and semantic-release figures out which one has to be used in which step. The properties related to each specific step allow you to customize with more details what runs on each step.

That allow for example to configure a plugin with certain options in plugins and override those options for a particular step.

Basically the specific options take precedence over the global ones.

How is it not what you expect? How would you improve the developer experience?

from git.

How would you improve the developer experience?

Probably, some warnings could be helpful in giving feedback about the fact that assets should be specified for the prepare step. Because I don't think they are used in publish, right?

I thought that in prepare and other steps I use kinda references to the specified plugin, and it turned out that they are used as independent instances.

from git.

Probably, some warnings could be helpful in giving feedback about the fact that assets should be specified for the prepare step. Because I don't think they are used in publish, right?

As indicated on the top of the README of this plugin the step supported are verifyConditions and prepare.
I don't there is a way to provide such warning as the code cannot guess if you meant to override the options on purpose or by mistake. As explained before, overriding the options for a specific step is a valid scenario.

I thought that in prepare and other steps I use kinda references to the specified plugin, and it turned out that they are used as independent instances.

The ability to configure individual step is there mostly for backward compatibility and for specific/advanced configuration (e.g. you don't want to run all the steps provided by the plugin or you want to run certain steps with overwritten options). To avoid confusion, the configuration of individual steps is mentioned in the doc anymore, as it's reserved for users who know the inner working of the plugin system.

So what make you think that you had to define those individual steps to reference what's in plugins?

from git.

I don't there is a way to provide such warning as the code cannot guess if you meant to override the options on purpose or by mistake.

It doesn't matter, the warning would be efficient way to provide the feedback.

To avoid confusion, the configuration of individual steps is mentioned in the doc anymore, as it's reserved for users who know the inner working of the plugin system.

Too bad, would be much better to have it in docs with the same explanation you made in the scope of this issue.

from git.

It doesn't matter, the warning would be efficient way to provide the feedback.

Is the warning you are suggesting is something like "You have overwritten asset, maybe you didn't do that on purpose"? I don't think that would be useful because you would have to do that for each property of each plugin and you would just spam a bunch of warning that nobody would read.

If we have to display a warning for everything that might or might not be a mistake from the user, we'll end up only doing that. We have a debug mode that display a lot info, in particular the config that end up being used for each plugin.

At some point I think it's fair to expect users to read the docs and use --debug to troubleshoot. And it's a better solution than implementing a bunch warnings for every mistake that we can think of.

I don't think warnings like "Hey! You configured that, but maybe you meant something else ¯_(ツ)_/¯?" bring much value. It's better to tell the user in a debug message "Here is the config that is going to be used" and expect the user to figure out that they are not actually configuring what they meant.

Too bad, would be much better to have it in docs with the same explanation you made in the scope of this issue.

It seems the problem was that you assumed that individual steps have to be implemented and reference the plugins from the plugins. I'm asking what make you think that, so we can fix it.
But as far as I can tell nothing in the doc suggest that. So maybe it's a blog post somewhere or something else?

from git.