Skip to content

Introduction

The JS API is what the GitHub Action is built on — and what you reach for when you need more: a release script for a different CI, a custom step order, or an adapter for a project type nobody has written yet.

Install the core package and the addons for your stack:

pnpm add @simple-release/core @simple-release/pnpm @simple-release/github

A release is a chain of steps on a Releaser:

release.js
import { Releaser } from '@simple-release/core'
import { PnpmProject } from '@simple-release/pnpm'
import { GithubHosting } from '@simple-release/github'
await new Releaser({
project: new PnpmProject(),
hosting: new GithubHosting({
token: process.env.GITHUB_TOKEN
})
})
.bump()
.commit()
.tag()
.push()
.publish()
.release()
.run()

Running it on a repository with unreleased feat and fix commits bumps the version in package.json, prepends the new section to CHANGELOG.md, commits, tags, pushes, publishes the package, and creates a GitHub release.

ConceptDescription
ManifestReads and writes the project version — package.json for the bundled addons, any file format for yours.
ProjectKnows how to bump and publish a project: single package or monorepo, npm, pnpm, or anything else.
HostingCreates releases and pull requests on the git hosting — GitHub out of the box.
ReleaserChains the release steps together: checkout, bump, commit, tag, push, publish, release.
ConfigLoads the .simple-release config file and instantiates addons from queries.

Nothing in the core is tied to JavaScript projects. The version lives in a manifest adapter, the bump and publish logic lives in a project adapter — implement those two for your platform and the whole pipeline works: changelogs, monorepos, maintenance branches, the GitHub Action.

The following pages build a small example alongside the API reference: a release adapter for a Python package with its version in pyproject.toml, published with twine — to show that “any platform” is meant literally.