reqlanOverviewIdeasFilesCode filesClustersAttributesGraphPrint

Idea detail

npm_distribution

reqlan rq/distribution/distribution.rq:17

block

Summary

npm publishing runs only when a `language/v*`, `analytical/v*`, or `cli/v*` tag is pushed.
Tags are created by deployment_flow; the npm workflow does not publish on ordinary commits.
The deploy workflow builds language / analytical / cli once, then publishes each package in sequence via `pnpm --filter <pkg> publish --access public --no-git-checks` ( language, then analytical, then cli ).
Before each package publishes, skip-already-published.mjs with `--filter <pkg>` checks the public npm registry and skips that step when the version is already published ( sets `should_publish=false` ). That avoids re-attempting already-published versions under OIDC.
Auth uses npm trusted publishing ( OIDC ) from GitHub Actions — no long-lived `NPM_TOKEN`.
Workflow requirements: `permissions.id-token: write`, Node ≥ 22. 14 with npm ≥ 11. 5. 1, registry `https://registry.npmjs.org`.
Each of `@reqlan/language`, `@reqlan/analytical`, and `@reqlan/cli` must have a Trusted Publisher on npmjs. com for GitHub Actions with org / user `littletuna4`, repository `reqlan`, workflow filename `deploy-npm.yml`, allowed action `npm publish`.
Package `repository.url` must match `https://github.com/littletuna4/reqlan.git`. Provenance attestations are generated automatically for public packages from this public repo.
Bootstrap: first publish of each scoped package can be done locally ( you must be logged in to npm as an `@reqlan` org member ) with `pnpm --filter @reqlan/language publish --access public --no-git-checks`, then analytical, then cli — or wait for the trusted-publisher CI path after packages exist and Trusted Publisher is configured.
Note: Changesets `ignore` only skips version bumps; packages must be `private: true` to skip local `changeset publish` ( `pnpm run release:npm` ) as with `reqlan-mcp` and `reqlan-extension`. CI publishes per-package and does not use `changeset publish`.
Published packages declare `publishConfig.access: public`.
Implementation: deploy-npm.yml, skip-already-published.mjs, and root `release:npm` in package.json for local changeset-based publish. Docs: trusted-publishers.

Jump to outbound references

Jump to inbound references

Navigation

Source file

reqlan rq/distribution/distribution.rq

 community 8

community cluster

distribution.rq

file cluster

reqlan rq/distribution

folder cluster

status: Not present

status cluster

tag: Not present

tag cluster

 Printable page

Static print-friendly idea sheet.

Ancestor context

deployment_flow

On push to main, if pending changesets remain, the release workflow applies them with `pnpm changeset version`. This bumps package. json for each affected package and writes changelogs. The workflow commits the result, creates annotated tags for every bumped publishable package, and pushes the commit and tags back to main. Release tags use `site/v{version}`, `ext/v{version}`, `language/v{version}`, `analytical/v{version}`, and `cli/v{version}` where `{version}` is the semver from that package's package. json. Deployment is tag-driven for every channel per ["./distribution.rq".release_tagging]; the release workflow only versions and tags. GitHub Actions pushes with the default `GITHUB_TOKEN` do not trigger other workflows, so site and npm deploy are also invoked directly from the release workflow. Optional `RELEASE_PAT` allows tag pushes to trigger downstream workflows for manual reruns and external CI. Recursive runs are prevented by skipping the release workflow for release commits. Tag patterns and downstream deploy workflows follow ["./distribution.rq".release_tagging]. The implementation lives in ["../../.github/workflows/release.yml"].

release_tagging

Deployment is tag-driven rather than commit-driven for every publishable channel. Tags are created automatically by ["./distribution.rq".deployment_flow], not manually. Site deployments are triggered by Git tags matching `site/v*` via ["./distribution.rq".site_distribution]. VS Code extension publishing is triggered by Azure DevOps tags matching `ext/v*` via ["./distribution.rq".extension_distribution] and ["./distribution.rq".openvsx_registry]. npm publishing is triggered by Git tags matching `language/v*`, `analytical/v*`, or `cli/v*` via ["./distribution.rq".npm_distribution]. The tag suffix after the channel prefix ( `site/v`, `ext/v`, `language/v`, `analytical/v`, `cli/v` ) equals the package. json version at that tag.

site_distribution

GitHub Pages deployment runs only when an `site/v*` tag is pushed. Tags are created by ["./distribution.rq".deployment_flow]; the site workflow does not deploy on ordinary commits. The implementation lives in ["../../.github/workflows/deploy-site.yml"].

extension_distribution

Azure DevOps builds, tests, packages, and publishes the VS Code extension only for tags matching `ext/v*`. Tags are created by ["./distribution.rq".deployment_flow]. The extension version comes from packages / extension / package. json at the tag; the pipeline must not overwrite it from the tag suffix. The implementation lives in ["../../azure-pipelines.yml"]. VSIX packaging follows ["./distribution.rq".vsix_export]. Marketplace publish is complemented by Open VSX per ["./distribution.rq".openvsx_registry].

openvsx_registry

The extension should be published to the Open VSX registry at https: / / open-vsx. org so it is installable in editors that use Open VSX instead of the Visual Studio Marketplace. Publishing should use the same tag-driven `ext/v*` releases as ["./distribution.rq".extension_distribution]. The packaged VSIX from ["./distribution.rq".vsix_export] is the artifact published to Open VSX. Azure DevOps is the authoritative publish workflow; Open VSX publish belongs in ["../../azure-pipelines.yml"] alongside marketplace deploy.

vsix_export

The VSIX includes logo assets from the extension media build: PNG for marketplace icon, language file icon, activity bar, and README; WebP as a raster fallback.