should not install `travis-deploy-once` as dev deps

[unional]

It is not useful in dev environment. IMO should keep it in .travis.yml as before. Install it globally in after_success. 🌷

[pvdlg]

Installing it in the devDependencies allow to not get a new major release (with breaking change) automatically and avoid to break your build accidentally.

In addition setting the command in script instead of after_success allow to fail the build if an error happen, so you get notified if a release fails.

As you mentionned it's a matter of opinion, and you have the possibility to do both as mentioned in the doc and the Travis recipe.

[gr2m]

I’d like to keep this as is for the reasons @pvdlg mentioned. People who know what they are doing can change it, people less tech savvy can get random errors of the sudden which the current setup does not.

[unional]

I would suggest to make it a prompt in the cli. Currently, for people like me, have to:

semantic-release-cli setup ... npm rm travis-deploy-once edit package.json to remove scripts/travis-deploy-once edit .travis.yml to change it to:

  - npm install -g travis-deploy-once
  - travis-deploy-once "npm run semantic-release"

In fact, I would love to do away scripts/semantic-release also. I would strive to keep package.json/scripts to all scripts developers can use at their dev environment. But that's more far-fetched. 🌷

[unional]

To elaborate a bit more why installing semantic-release as devDep is also a bad idea:

The usage of semantic-release has changed from semantic-release pre && npm run publish && semantic-release post to semantic-release. That breaks many packages and have to be fixed manually.

Also, semantic-release really works only when it works with some CI. This means the information/context required for semantic-release to work is in two places: the semantic-release package installed from npm, and configuration of specific CI. This cannot be done together by npm install semantic-release@*.

So when semantic-release releases a breaking change that requires changes from package.json/scripts and/or CI configuration, the whole system breaks down and need to be patched manually.

It is much better to have everything in one place. e.g.

# .travis.yml

  - npm i -g semantic-release-cli
  - semantic-release-cli publish

[kbrandwijk]

Adding an extra question to the CLI while probably most of the users would want the default behavior doesn't seem like the best option, because that CLI experience should be as smooth as possible.

What I am open to, is an rc (global config) for semantic-release, where you could specify these kind of 'advanced options' to be used by the CLI. There are some other questions in the CLI that could benefit from a global config (like asking which CI you use, and maybe some or all of the other defaults).

For example, a user that always uses the public NPM registry, and the same Github account, and always uses Travis, and wants the semantic-release installation step in their .travis.yml, could save all that to the rc file, and run semantic-release-cli setup without a single question.