npm publish workflow

[JanKuczma]

No description provided.

[Copilot]

Pull Request Overview

This PR adds an automated NPM publishing workflow using GitHub Actions and updates the package version. The workflow allows manual triggering with configurable version bumping and includes automated tagging and release creation.

• Adds a comprehensive GitHub Actions workflow for NPM publishing with manual dispatch triggers
• Updates package version from 1.0.0 to 0.1.6
• Includes automated version management, git tagging, and GitHub release creation

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
ts/lib/package.json	Updates version number from 1.0.0 to 0.1.6
.github/workflows/publish-npm.yml	Adds complete NPM publishing workflow with version management and release automation

Comments suppressed due to low confidence (1)

.github/workflows/publish-npm.yml:68

• The action 'actions/create-release@v1' has been deprecated. Consider using 'actions/[email protected]' or the newer 'softprops/action-gh-release@v1' for better maintenance and security.

        uses: actions/create-release@v1

[Marcin-Radecki]

Imho it's less work to just read version from package.json, instead of committing it. And it's more intuitive approach, ie it is package.json which is golden source of version, instead of relying on developer putting some version here. We can then get rid out of this input, and instead make input like ref (see here https://github.com/Cardinal-Cryptography/blanksquare-monorepo/blob/main/.github/workflows/_build-enclave-artifacts.yml#L7-L10), so that one can put as this ref SHA or some git tag.

[kroist]

agree, version should be hardcoded into package.json. (it already is)

[Marcin-Radecki]

I'd create GitHub release only on when git tag is pushed. So this even another approach than I suggested in my previous message - trigger this workflow on git: push: tags, then we don't need ref input even. This has a downside, like sometimes we change workflow and they are bugs in workflows from time to time, when we make tag is immutable, and if there's a bug in the workflow we are forced to tag one more version e.g. 1.0.1, even though we did not change package itself.

[kroist]

agree, version should be hardcoded into package.json. (it already is)

[kroist]

I'd remove most of things after that point. It can be simply:

• npm push
• gh release with the link to npm@version