add workflow for publishing npm package

[lenkan]

This is a suggestion of an automated workflow for publishing npm packages.

Process for publishing the development tags would be:

1. Create a PR for the next intended npm package version x.y.z
   • Most often this would the next minor release for new features. While we are still on v0, we also include breaking changes here. Once we hit v1, we will have a more strict process for how to bump version numbers. Perhaps something like this https://www.npmjs.com/package/semantic-release.
2. Once merged, a maintainer can publish next dev-version Actions => Publish NPM => Run workflow
   • 
3. The workflow does this
   1. Set the version fo x.y.z-dev.<commit-sha>
   2. Publish the npm package to npm registry
   3. Creates a git tag vx.y.z-dev.<commit-sha>
   4. Push git tag

If this works well, we can trigger this workflow to run on push to main for a completely automated publishing flow.

Once the next release is ready you change the npm dist tag input to latest. Then the workflow does

1. Publish the npm package with version x.y.z to npm registry
2. Creates a git tag x.y.z
3. Push git tag

This can then also be easily extended to utilize https://cli.github.com/manual/gh_release_create for automatic github release creation with changelog.

Usage

If consumers of the library want to install the lastest dev version they would do:

npm i --save signify-ts@dev

They can also explicitly install the version from a commit using

npm i --save [email protected].<commit-sha>

To install the latest released version they would continue to use

npm i --save signify-ts@latest

Or simply use a version number

npm i --save [email protected]

As long as they use a lock file, the version that they have installed in their project will not change unless they explicitly want to upgrade.

Discussion

In order to make this work, someone with push access to the npm package signify-ts needs to generate a publishing token and store in github secrets. These secrets are not accessible from forks.

This would make it easier for consumers of this package to install and test the latest versions of the package without having to reference the repository and pull all devDependencies. It would also make it easier for maintainers to publish the packages.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.51%. Comparing base (6113497) to head (1bf3e33).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #260   +/-   ##
=======================================
  Coverage   83.51%   83.51%           
=======================================
  Files          46       46           
  Lines        4210     4210           
  Branches     1047     1047           
=======================================
  Hits         3516     3516           
+ Misses        690      666   -24     
- Partials        4       28   +24     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lenkan]

Update: I thought a bit more about this and I think the main benefit is to make it easier to publish dev versions automatically. However, I have second thoughts about putting the "logic" for determining the version number in the workflow. It is probably better to but in a script, the workflow would just invoke the script using appropriate environment variables. Can also add a Makefile similar to the other repos.

Essentially I'd like the end result to be something like:

1. Push changes to main
2. A workflow automatically (or after manual approval) publishes the package under x.y.z-dev. version.
3. Some time passes and a the package is ready for new release
4. Maintainer starts workflow with "latest" dist tag
5. Workflow publishes the package under x.y.z version (from package.json)
6. Maintainer creates a PR and bumps version to next minor x.w.0
7. Following PRs will be merged and released under x.w.0-dev. until x.w is ready to be released.

I have not thoroughly considered how to handle release branches.

[pfeairheller]

@lenkan The secret NPM_DEPLOY_SECRET has been created with WRITE access to signify-ts.