@turri-dev/cli 0.2.2 → 0.2.3-next.85fd5c6

package/README.md

@@ -203,6 +203,8 @@ Start at the [documentation index](docs/README.md), or go straight to a page:
 | [The \*\*\*plain parser](docs/parser.md) | the TypeScript port, `turri parse`, fidelity to the reference parser |
 | [Theming](docs/theming.md) | the two brand themes |
 | [Development](docs/development.md) | tests, layout, known edges |
+| [Contributing](CONTRIBUTING.md) | reporting a bug, making a change, the conventions a pull request follows |
+| [Security](SECURITY.md) | reporting a vulnerability, privately |
 
 ## License
 

package/docs/development.md

@@ -7,6 +7,8 @@ npm test            # the whole suite, about a minute
 
 The suite runs the projects' testing scripts on this machine, as turri does. The fixture scripts stage each run in a folder of their own, as test files running side by side would otherwise share one.
 
+`.github/workflows/test.yml` runs both on GitHub for every pull request and every push to `main`, and `.github/workflows/commits.yml` checks that each of a pull request's commits is a Conventional Commit, with no fixup and no merge commit - a pull request is rebased onto `main`, each commit as it is. A pull request from a fork runs them once the maintainer has approved its run - see [contributing](../CONTRIBUTING.md).
+
 ## Mutation testing
 
 `npm run mutation` runs [Stryker](https://stryker-mutator.io) over the core of regeneration - the parts in `stryker.config.mjs` - one part at a time, each part's report in `reports/mutation/<part>/`. A part with a report is skipped, so a run that is stopped goes on from the part it was in; `npm run mutation -- <part>` runs one again, and `npm run mutation -- --summary` sums up the reports there are. It takes hours: each part runs the suite once to find which tests reach which mutant (`vitest.stryker.config.ts`, the suite without the files that run real commands behind the sandbox), then each mutant against those tests. `scripts/mutation.mjs` sets two things in Stryker's vitest runner the suite needs - forked workers, and a test-name filter that matches vitest 5's names - again after every `npm install`.
@@ -22,7 +24,7 @@ The package on npm is built: Node runs no `.ts` file inside a `node_modules`, so
 `.github/workflows/publish.yml` publishes `@turri-dev/cli`, after the typecheck and the suite pass:
 
 - every push or merge into `main` publishes a prerelease under the `next` dist-tag - the patch after the `latest` on npm, with the commit's sha: `0.1.2-next.<sha>`. `latest` is not touched; `npm install -g @turri-dev/cli@next` gets it.
-- a GitHub Release tagged `vX.Y.Z`, published by hand, publishes `X.Y.Z` as `latest` (or under `next`, if the release is marked a pre-release). The tag is the version: it is set in the runner and never committed, so `package.json`'s version on `main` is stale by design.
+- a GitHub Release tagged `vX.Y.Z`, published by hand, publishes `X.Y.Z` as `latest` (or under `next`, if the release is marked a pre-release). The tag is the version: it is set in the runner and never committed, so `package.json`'s version on `main` is stale by design. Once npm has a release on `latest`, it is posted to the Discord channel whose webhook is the repository secret `DISCORD_RELEASE_WEBHOOK` - its name, its notes and the command that updates; without the secret nothing is posted.
 
 The workflow signs in to npm with npm's trusted publishing (OIDC), not a token: the package's settings on npmjs.com trust `turri-oss/turri`, the workflow `publish.yml` and the environment `npm`. Renaming the workflow file breaks it.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@turri-dev/cli",
-  "version": "0.2.2",
+  "version": "0.2.3-next.85fd5c6",
   "license": "MIT",
   "type": "module",
   "repository": {