Publishing

Scalar publishes your generated SDKs to their package registries for you. Instead of running npm publish by hand, Scalar writes GitHub Actions workflows into your SDK repository and drives them from your SDK configuration. When you merge a build, the package goes out.

Publishing is opt-in and off by default. Nothing is published until you turn it on for a target.

How it works

Publishing rides on top of the generation and GitHub sync you already use. There is no separate pipeline to maintain.

What gets generated

Every target with a linked repository gets two workflows committed alongside the SDK. They are normal, readable workflow files you can inspect (and edit) in your repo.

Enable publishing

You can enable publishing two ways. Both set the same thing.

From the dashboard, open a target and toggle Publish to <registry> on merge under Git settings.

In your configuration, add a publish block to the target:

{
  "targets": {
    "typescript": {
      "packageName": "demo-api",
      "version": "0.3.1",
      "publish": {
        "npm": true
      }
    }
  }
}

The registry key depends on the target (npm, pypi, cargo, maven, and so on). For the full list and per-registry options, see Package Registries. Each target documents its publish options on its configuration page.

Authentication

By default Scalar uses OIDC trusted publishing. The release workflow exchanges a short-lived GitHub identity token for a registry credential at publish time, so there is no token to create, store, or rotate. You register your repository and the sdk-release.yml workflow as a trusted publisher on the registry once.

Registries that do not support OIDC (and Maven Central, which needs GPG signing) use repository secrets instead. Setup for each registry is covered in Package Registries.

Versioning and releases

Versioning is driven by your configuration, not inferred from commit messages. The version that ships is the target's version (falling back to the SDK version). Bump it when you want a new release; every merged build is tagged and released as vX.Y.Z.

Scalar creates a GitHub Release for each version and maintains a CHANGELOG.md in the repository, so your release history lives in your repo next to the code.

Permissions

The generated release workflow requests only the permissions it needs:

permissions:
  contents: read
  id-token: write
  packages: write

id-token: write is what enables OIDC trusted publishing. The CLI target uses contents: write instead, because it uploads built binaries to the GitHub Release. Scalar never asks for organization-wide access to publish.

Next steps