Set up CI to publish npm packages #79

New Issue

GiteaMirror · 2026-02-28T18:48:00-06:00

GiteaMirror commented

2026-02-28 18:48:00 -06:00

Originally created by @fuzzmz on GitHub (May 5, 2022).

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

Originally created by @fuzzmz on GitHub (May 5, 2022). 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

GiteaMirror closed this issue

2026-02-28 18:48:00 -06:00

GiteaMirror commented

2026-02-28 18:48:00 -06:00

@fuzzmz commented on GitHub (May 5, 2022):

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?

@fuzzmz commented on GitHub (May 5, 2022): 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 `semver`ish?

GiteaMirror commented

2026-02-28 18:48:01 -06:00

@MatissJanis commented on GitHub (Jan 12, 2023):

👋 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 commented on GitHub (Jan 12, 2023): 👋 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.

GiteaMirror commented

2026-02-28 18:48:01 -06:00

@MatissJanis commented on GitHub (Mar 30, 2023):

Closing this off due to inactivity.

@MatissJanis commented on GitHub (Mar 30, 2023): Closing this off due to inactivity.