Add typed object selection, transformation, clone, merge, freeze, flatten and diff helpers. Add text normalization, truncation, search, masking, parsing, wrapping and formatting utilities. Document behavior and update bundle budgets.
2.8 KiB
Repository guidance
Keep README.md focused on package usage and installation. Document development
checks, CI workflows, and release procedures in this file. This repository uses
Gitea at https://git.warky.dev; workflows belong in .gitea/workflows/.
Development checks
pnpm-workspace.yaml explicitly allows esbuild install scripts through
allowBuilds for pnpm versions that require dependency build approval. Keep
approvals scoped to the dependencies that need them.
Run pnpm test for the test suite and pnpm check:bundle for a production build
with bundle checks. Builds fail on direct eval warnings. The bundle check measures
raw and gzip bytes for every emitted JavaScript file against
scripts/bundle-budgets.json; missing outputs and unbudgeted chunks also fail.
Review intentional size changes before updating budgets. Gitea Actions runs both commands on
pushes and pull requests via .gitea/workflows/ci.yml, using a runner with the
ubuntu-latest label. Action sources use explicit URLs so they do not depend on
the server’s default action host. No additional runtime dependencies are required by the
collection or sorting helpers.
Publishing to Gitea Packages
.gitea/workflows/publish.yml publishes @warkypublic/artemis-kit when a v*
tag is pushed to Gitea. The destination is
https://git.warky.dev/api/packages/<owner>/npm/, where <owner> is the Gitea
repository's user or organization (not necessarily the npm scope warkypublic).
- The workflow uses the existing
PACKAGE_REGISTRY_TOKENActions secret. It must have Packages: Read & Write access from a user allowed to publish under the repository owner. npm token authentication does not require the existingPACKAGE_REGISTRY_USERNAMEsecret. Do not put the token in the repository. - Run
pnpm exec changeset versionto apply pending changesets. Review and commit the updated version, changelog, and consumed changesets with the release changes. - Create and push a matching tag to the Gitea remote, for example
v1.1.0for package version1.1.0. The workflow rejects mismatched tags, runs the tests and bundle checks, then publishes using pnpm so thepublishConfigoverrides point consumers to the built JavaScript and declarations.
Stable versions receive the latest dist-tag; prereleases receive next.
Existing package versions cannot be overwritten; release a new version instead.
This workflow adds Gitea as a publishing destination without changing the default
registry for local publishing. After the first upload, link the package to this
repository in the package settings to show it in the repository's Packages tab.
See the Gitea npm registry documentation
and package access rules.