What should be the next Feature?

[hdorgeval]

Hi guys, I open a new issue where you can vote for the next-to-have feature in publish-please.

Feel Free to add any missing nice-to-have or must-to-have feature by adding a new comment.

[hdorgeval]

Do not report vulnerabilities for dev dependencies

[hdorgeval]

Be able to publish under custom credentials

npm run publis-please --userconfig ~/.npmrc-myuser-config

Instead of publishing under the current logged-in user, be able to publish under a specific user

[hdorgeval]

Integrate license-checker as a new kind of validation

Create a new kind of validation for license-checker. Goal behind this would be that one would be able to verify if the project uses a license which is forbidden by a policy (e.g. fail on GPL licenses)...

[hdorgeval]

Support .publishrc.json

As a user I want to be able to rename the .publishrc to .publishrc.json at any time after the installation of publish-please

[hdorgeval]

have an option "warn" for validations

Be able to publish even when a validation fails, without having to disable this validation in the .publishrc file

[hdorgeval]

Add npm shrinkwrap validation

Be able to check the version in npm-shrinkwrap.json matches version in package.json and git tag

[AndreyBelym]

Check Github status of the master's HEAD commit as a new kind of validation

Github allows external CI services like Travis CI, Cirecle CI, etc. to run tests for a commit and report their statuses as passed/failed. publish-please can retrieve combined status of tests using Github Statuses API (e.g. https://api.github.com/repos/inikulin/publish-please/commits/f76ce2c7ff7d061ca44278962219c816522c128d/status) and prevent publishing if the status doesn't equal to "passed".

E.g. for the https://github.com/DevExpress/testcafe-hammerhead: enabling this option would mean that the latest release could not be pubished (v14.0.0: Bump version (#1641)): https://api.github.com/repos/DevExpress/testcafe-hammerhead/commits/0cce6e4/status

[hdorgeval]

Be able to run publish-please without emoji (-> delivered in v5.3.0)

npm run publish-please --ci

[hdorgeval]

Be able to prevent publishing when a dependency points to github

It would be great that publish-please detect any direct dependency to github or to local package file and then prevents publishing.

[artivilla]

Automated Changelog

Hi @artivilla, very nice idea. Do you have any advice on which tool to use for this feature?

[jehy]

Check for trash files which should not be published. https://github.com/inikulin/publish-please/issues/75

[artivilla]

@hdorgeval This tool simply focuses on generating changelogs -- https://github.com/zeit/release. There are other tools like release-it that come with this inbuilt but has similar features to publish-please.

[BillyBlaze]

Custom reporters or ability to disable elegantStatus (-> delivered in v5.3.0)

In addition to the feature request without emoji, it would also be great to create different output for CI's.

Currently if you run publish-please in TeamCity you get output like this:

[14:11:52][Step 2/3]  [?25l\ Checking for the vulnerable dependencies
[14:11:52][Step 2/3]  [?25l [1000D [K [1A [1000D [K| Checking for the vulnerable dependencies
[14:11:52][Step 2/3]  [?25l [1000D [K [1A [1000D [K/ Checking for the vulnerable dependencies
[14:11:52][Step 2/3]  [?25l [1000D [K [1A [1000D [K- Checking for the vulnerable dependencies
[14:11:53][Step 2/3]  [?25l [1000D [K [1A [1000D [K\ Checking for the vulnerable dependencies
[14:11:53][Step 2/3]  [?25l [1000D [K [1A [1000D [K| Checking for the vulnerable dependencies
[14:11:53][Step 2/3]  [?25l [1000D [K [1A [1000D [K/ Checking for the vulnerable dependencies
[14:11:53][Step 2/3]  [?25l [1000D [K [1A [1000D [K- Checking for the vulnerable dependencies
[14:11:53][Step 2/3]  [?25l [1000D [K [1A [1000D [K\ Checking for the vulnerable dependencies
[14:11:53][Step 2/3]  [?25l [1000D [K [1A [1000D [K| Checking for the vulnerable dependencies
[14:11:53][Step 2/3]  [?25l [1000D [K [1A [1000D [K/ Checking for the vulnerable dependencies
[14:11:53][Step 2/3]  [?25l [1000D [K [1A [1000D [K- Checking for the vulnerable dependencies
[14:11:53][Step 2/3]  [?25l [1000D [K [1A [1000D [K\ Checking for the vulnerable dependencies
[14:11:53][Step 2/3]  [?25l [1000D [K [1A [1000D [K| Checking for the vulnerable dependencies

While it would be great to just have just a plaintext output with something like:

[v] Checking for the vulnerable dependencies
[x] Validating branch

[hdorgeval]

Hi @BillyBlaze. Thank you for your great feedback. I did not know that publish-please was used in TeamCity. Because I am using TeamCity in my every day job, I fully understand your pain.

So this topic will be the next PR. If you want to contribute and create a PR you are welcome.

I suggest to take the reporter plugin path. Maybe you have some ideas on how to implement a reporter plug-in.

The idea would be to create and publish a reporter with the following package naming convention: publish-please-reporter-xxxxx

publish-please will by default use a publish-please-reporter-elegant For Teamcity I/you will have to create a package named publish-please-reporter-teamcity

publish-please will then have a new cli option (similar to what is done in TestCafé):

npm run publish-please -r teamcity

or

npx publish-please -r teamcity

So anybody that can advise me on how to implement such reporters is welcomed. @inikulin, @AndreyBelym : does it make sense for you to go this way?

[inikulin]

@hdorgeval as an alternative solution I can suggest using https://www.npmjs.com/package/is-ci to check for CI environment and just disable elegant status when required.

[hdorgeval]

@inikulin thank you for your suggestion. I will go your way and I suggest to create two internal reporters: one for elegant status and one for CI. At runtime, based on ìs-ci package the active reporter will be either the 'elegant status' reporter or the 'CI' reporter. Maybe it could be valuable to add a --ci option on the command-line to be able to force the reporter to be the 'CI' reporter whatever the environment is. What do you think of this approach?

[inikulin]

@hdorgeval makes perfect sense to me, many CLI tools use the same approach.

[hdorgeval]

Hi @BillyBlaze, your proposal has been published in version 5.3.0. See the README for more details. Could you give it a try?

[BillyBlaze]

Hi @hdorgeval,

Thanks for your hard work! I have upgraded it and it looks great, the only comment I have is that some special characters still look funny.

[09:46:02]  [Step 2/4] √ Checking for the vulnerable dependencies
[09:46:02]  [Step 2/4] √ Checking for the uncommitted changes
[09:46:02]  [Step 2/4] √ Checking for the untracked files
[09:46:04]  [Step 2/4] × Checking for the sensitive and non-essential data in the npm package
[09:46:04]  [Step 2/4] √ Validating branch

[hdorgeval]

Hi @BillyBlaze, thank you very much for your feedback. I completely missed the point that characters like '√' '✓' '×' '✖' are not rendered correctly on Teamcity. I will solve this issue as soon as possible.

[hdorgeval]

Hi @BillyBlaze your TeamCity issue has been solved in version 5.4.2. See the PR #88 for more details. Could you give it a try?

[kailashyogeshwar85]

Configuration to specify branch for publishing prerelease build rather than manually updating .publishrc file @hdorgeval

[AndreyBelym]

Support publishConfig from package.json

Recent npm versions support setting publish tags, access levels, and registry URLs via the publishConfig field in package.json: https://docs.npmjs.com/files/package.json#publishconfig