Proposal for a refined publish flow

[jkrems]

I'd like to spend some time on this module to make the flow a little smoother (and add some features that are a bit manual right now. In the end I'd like to end up with something like the following flow:

Configuration

package.json

• publishConfig.registry: Used by npm when publishing and also by npub when installing dependencies
• private: If true, the package shouldn't be published to any registry.
• publishConfig.license.exclude: (deprecated) Use npub.license.exclude.

  npub Settings

npub uses rc combined with the npub section of package.json. Settings loaded via rc override settings in package.json.

• license.exclude: An array of directories and/or files to ignore for the npub prep command.
• branch: The branch to release from, defaults to master.
• github.baseUrl: The base url when talking to the Github API, defaults to https://api.github.com.
• github.token: A Github access token. Never check access tokens into version control.
• npm.publish: If npub should be publishing the package to npm, defaults to true.

  Commands

  npub publish [ <version> ]

  Options

• -t/--test command: Alternate test suite command, default: npm test
• --dry: Don't actually publish or commit anything
• --yes: Don't ask for confirmation, this allows to run npub publish as part of a CI build of master
• <version>, one of:
  • 1.2.3: Publish as a specific version number
  • patch, minor, major: Increment the existing version (like npm version patch would)
  • No version: npub will try to deduce it from the Github PRs that were merged, using semver-minor style labels.

    Steps

    1. Verify: No uncommitted changes (npub verify)
    2. Switch to release branch
    3. Pull with fast forward only from remote in package.json
    4. Add license headers if necessary (npub prep)
    5. Verify: No uncommitted changes (npub verify)
    6. Remove node_modules
    7. Run npm install using publishConfig.registry if available
    8. Run the test suite
    9. Verify: No uncommitted changes (npub verify) - maybe not necessary..?
    10. Prepare changelog from Github API and/or commit log
    11. Open editor with temp change list
    12. Update package.json with new version and CHANGELOG.md with change list
    13. Commit CHANGELOG.md & package.json
    14. Tag with the version number (prefixed with v, e.g. vX.Y.Z)
    15. Ask for confirmation to continue (unless --yes was used)
    16. Git push the branch and the tag
    17. Create a Github release
    18. npm publish (unless private: true or publish is disabled, e.g. because the project uses CI to publish)

The Github integration should fulfill the following requirements:

• Works with public Github and Github Enterprise
• Can run in CI (e.g. via a CI secret with an access token)
• The access token doesn't appear in logs, no matter how verbose they are
• Can be configured locally, preferably with nice instructions if the config is missing

[jkrems]

cc @danmconrad @khoomeister

[ghost]

How does it know what the release branch is?

[jkrems]

@khoomeister Default to master, optional config option. Maybe I should spell out the config options explicitly. Good point.

[jkrems]

There was a revision where I also had "and after the release, you can push it to additional branches, e.g. you release from develop and push to develop and master". But then I thought - if you do the continuous releases whenever you merge a PR, splitting the two is kind of silly anyhow.

[jkrems]

Moved to https://github.com/EndangeredMassa/npub/pull/50 so inline comments etc. work.