Embrace 10.0.0

[felixfbecker]

• Only run semantic-release, not pre and post
• It would be nice to ask whether the package should be published to npm, or possibly some other setups for different package managers
  • If not npm, would not set up an NPM_TOKEN and unset all defaults
  • If for example VS Code extensions, would add a dependency on semantic-release-vsce to package.json
  • If Composer, only use @semantic-release/last-release-git-tag
• Travis setup should ask whether you want to use build stages or not (default yes). If yes, set up config so that condition-travis doesn't conflict and set recommended stage conditions etc. Related https://github.com/semantic-release/condition-travis/issues/96

[pvdlg]

As mentioned in this comment it would be a good idea to refactor the CLI using yeoman.

Would you be interested in modifying the current cli or working on a brand new one?

[gr2m]

I like the issue title :) To "fully embrace semantic-release@10", would it mean there would be multiple CLI tools? Or one CLI tool with a plugin architecture? Or with yeoman, would there be no custom CLI at all any longer, but different generators for different semantic-release presets?

The latter makes a lot of sense to me :) I’m not using yeoman myself and don’t see it being used a lot myself any more. Do I need to install the yo cli tool first before running the semantic-release generator? Or would we still have our own cli with npm install semantic-release-cli tool but just use yo as a framework?

[pvdlg]

My understanding is that yeoman would do a lot of the thing we already do with custom code in the cli. It would be use as a framework, meaning we would still have the same unique cli package, but it would use yeoman generator to ask the questions and modify the files.

[felixfbecker]

I think having to install different plugins kinda defeats the purpose of the CLI, which is supposed to be the single entry point to configuring all plugins for you. I would rather add options for a few popular package managers (and the community can contribute more, but it won't be that many).

@pvdlg could you be a bit more specific? Looking at a couple of yeoman generators, I don't see anything that helps us, inquirer already abstracts asking the questions. @gr2m For yeoman, users would have to install yeoman first, which is not optimal.

[gr2m]

Just want to clarify: I don’t mind moving to Yeoman, even if folks have to install another tool first. I'm always happy to use other Open Source projects if it’s a good fit, and from the sound of it, this is potentially a great fit.

I’d like to see how it feels with Yeoman first. I could imagine it would be simple for folks who do things like semantic-release-docker to also provide a custom yeoman generator. From a perspective of maintainability, this will work much better than having one CLI tool that we try to make work for all use cases