Set up CI to publish npm packages

[fuzzmz]

Set up CI to publish new versions of @actual-app/api and @actual-app/web to npmjs.org.

I see this is a prerequisite to setting up any CI/CD for actual-server. Whenever new versions of the api and web will be published we'd ideally trigger an update of the requirements in actual-server and build an updated Docker image for it.

Having an auto-updated package.json also simplifies keeping things up to date on fly.io

[fuzzmz]

I will start working on this next week.

@jlongster, all, have a couple of questions around implementation:

• do we publish to npmjs.org on commits on master or do we want to publish only when tagged?
• do we have separate publish flows for @actual-app/api and @actual-app/web? This might make sense if we want them to be decoupled, so that when we'd have changes in the desktop-client we'd only publish that, but when we'd have changes in api we'd rebuild the full tree
• do we commit back the bumped versions in package.json? I'd go with yes.
• how do we increment? do we bump minor on each build, or go with something more semverish?

[MatissJanis]

👋 Apologies for the super slow response.

do we publish to npmjs.org on commits on master or do we want to publish only when tagged?

Lets go with only when tagged.

do we have separate publish flows for @actual-app/api and @actual-app/web? This might make sense if we want them to be decoupled, so that when we'd have changes in the desktop-client we'd only publish that, but when we'd have changes in api we'd rebuild the full tree

Yes, please separate. The API changes pretty rarely whereas web changes quite often.

do we commit back the bumped versions in package.json? I'd go with yes.

yes

how do we increment? do we bump minor on each build, or go with something more semverish?

Currently we follow date-format. So for example: 23.1.12 release was released in 2023 on the 12th of January.

[MatissJanis]

Closing this off due to inactivity.