Transparent and flexible change management for publishing packages and assets. Publish and deploy from a single asset repository, monorepos, and even multi-language repositories.
The documentation can be found in the main covector folder. It is placed there that it will be packaged when publishing to npm.
Below is a list of all of the packages within this repository. The usage and docs are in the main covector folder.
These projects run covector. Each one lists its config, then the version job, the publish job, and the PR status or meta jobs.
tauri-apps/tauri: Desktop and mobile apps with a Rust core and a TS layer. It is the multi-language setup covector was built for.
- Config: dual
rustandjavascriptmanagers, uses custom change tags that shape the changelog. - Version: on push to
dev, change files trigger a version bump into an "Apply Version Updates" PR whose body is the assembled change summary. - Publish: once no change files remain, the same workflow publishes to crates.io and npm with provenance, cuts GitHub releases, and kicks off the downstream CLI publishing workflows.
- Status / fork: comments the pending changes on every PR; the fork job re-posts via
workflow_runsinceGITHUB_TOKENcan't comment there directly.
tauri-apps/plugins-workspace: 30+ official plugins, Rust crates and npm packages versioned together.
- Config: each package lists its dependencies so bumps cascade through the graph in order.
- Version: on push to
v1orv2, change files become a version bump PR. - Publish: when the change files are gone, every crate and npm package with changes is published.
- Status / fork: comments the pending changes on every PR.
tauri-apps/wry: the WebView library and tauri-apps/tao: the windowing library for Tauri.
- Configs (tao): crates.io publish checks, cargo audit before every publish, and a custom
housekeepingbump type. - Version and publish (tao): one workflow on push to
devhandles both legs. - Status / fork, mirrored in tao (fork).
thefrontside/simulacrum. Foundational elements to write simulators to mimic real APIs. Includes Auth0 and the GitHub API simulators.
- Config: npm publish with provenance, a postpublish check that each package actually landed on the registry, and a custom
housekeepingbump type for chores. - Version: on push to
main, change files direct generation of a draft version PR. - Publish: when the change files are gone,
pnpm publishgoes out with provenance and apreviewtag where configured. - Meta: posts the pending changes on PRs including forks via
workflow_run.
thefrontside/interactors. Deno packages. Covector never touches a registry here; it pushes tags which trigger a Deno release within JSR.
- Config: swaps the publish step for
git tagcommands and reads published versions back from the tag list. - Version: on push to
main, change files become a version PR. - Publish: the publish leg cuts and pushes a
pkg-vN.N.Ntag per package, expecting that push to trigger the deno publish. - Status comments the pending changes on PRs, and a fork job re-posts them via
workflow_run.
jbolda/finatr. One repo, two targets. The web package deploys to Netlify, the app package ships Tauri binaries to a GitHub release.
- Config: points each package at its target and marks
appas depending onwebso it versions second. - Version: the
version-or-releasejob bumps into a version PR on push tonext. - Publish: when it's time to publish,
tauri-actionbuilds the desktop app across four platforms onto the GitHub release, thenpublishdeploys the site with netlify-cli. - Status: comments the pending changes on PRs.
Using covector in your project? We would love to hear about it!