Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restrict semver increments #537

Closed
terenceodonoghue opened this issue May 19, 2020 · 2 comments
Closed

Restrict semver increments #537

terenceodonoghue opened this issue May 19, 2020 · 2 comments

Comments

@terenceodonoghue
Copy link
Contributor

terenceodonoghue commented May 19, 2020

Description

Using a flag or a config file, restrict the available semver ranges when running np.

Is the feature request related to a problem?

In a shared repo, there may be different understandings of what is and isn't a major release. Once published, it can be difficult (not to mention bad practice) to roll back if done in error. It would be ideal to have a passive means of preventing accidental publication of a version that is otherwise reserved for changes of a particular nature.

Possible implementation

Add a versions key to np-config which could function as a whitelist...

"versions": ["patch", "minor"]
  Select semver increment or specify new version (Use arrow keys)

  patch         0.0.1 
  minor         0.1.0 

...or a blacklist:

"versions": ["major", "premajor"]
  Select semver increment or specify new version (Use arrow keys)

  patch         0.0.1 
  minor         0.1.0 
  prepatch      0.0.1-0 
  preminor      0.1.0-0 
  prerelease    0.0.1-0 

Alternatives

Create flags such as --no-major or --versions patch, minor to include in an npm script.

@sindresorhus
Copy link
Owner

I think there's a better non-technical solution to this: Don't give people publish access if you cannot trust them to do the right thing. Even if we were to add this, there would be nothing stopping them from just running npm version major && npm publish.

@terenceodonoghue
Copy link
Contributor Author

Thanks @sindresorhus; thought it worth suggesting, but you make a valid point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants