96 lines
6.9 KiB
Plaintext
96 lines
6.9 KiB
Plaintext
Tasks
|
|
|
|
Backlog and tracking for tiny-pattern-ts. Managed in vscode-todotasks format.
|
|
|
|
---
|
|
|
|
Setup:
|
|
✔ Add gitea release page in CI @high @done
|
|
✔ Manually verify the Gitea release page on a real tag push (needs main) @high @done (9/15/2026, 1:18:15 PM)
|
|
☐ Split off template into separate package => pi --session 01a07dde-7050-7054-bb36-1606d7eb2bc3 @high
|
|
|
|
v1.0:
|
|
☐ API surface is stable and fully typed
|
|
☐ Finalize public exports in `src/index.ts`
|
|
☐ Document all exported types and functions
|
|
☐ Add JSDoc for public APIs
|
|
☐ Test coverage meets threshold
|
|
☐ Achieve 100% branch coverage on `src/pattern.ts`
|
|
☐ Achieve 100% branch coverage on `src/match.ts`
|
|
☐ Achieve 100% branch coverage on `src/index.ts`
|
|
|
|
Bugs:
|
|
|
|
Enhancements:
|
|
|
|
Documentation:
|
|
✔ Clean up CONTRIBUTING.md and README.md, create docs @done
|
|
✔ Review existing documentation for accuracy and completeness @done
|
|
✔ README.md should be the main entry point for users, and CONTRIBUTING.md should be the main entry point for contributors @done
|
|
✔ Move the decisions, shortcomings and known issues out of README.md and CONTRIBUTING.md @done
|
|
✔ Decided: category files under development/ (one per area), not ADRs. Each decision is a block with #### Decision (YYYY-MM) / #### Why / #### Rejected / #### Known issue; rationale in development/README.md @done
|
|
✔ have a look at other well known repositories for inspiration on how to structure the docs @done
|
|
✔ often times a docs folder is used, but this usually contains further user of the library documentation, that is deployed to a website. Deployment is out of scope for now @done
|
|
✔ make sure to preserve that information in the new docs @done
|
|
✔ development/README.md - index and decision-block convention @done
|
|
✔ development/workflow.md - branching, script prefixes, feedback tiers, commits @done
|
|
✔ development/tooling.md - toolchain decisions and editor setup @done
|
|
✔ development/testing.md - type-driven testing @done
|
|
✔ development/ci.md - pipeline, runner image, coverage serving @done
|
|
✔ development/publishing.md - release and npm publishing @done
|
|
✔ development/library.md - public API design and its limitations @done
|
|
✔ README.md @done
|
|
✔ I really like the order perl documentation does it: name with a single line description, version, Synopsis, Description, examples, API reference, license @done
|
|
(example: https://metacpan.org/pod/Scalar::Util)
|
|
✔ should include a clear description of the library, its purpose, and how to use it @done
|
|
✔ Add usage examples to README.md @done
|
|
✔ version needs to be kept in sync with package.json in release.sh @done
|
|
✔ Not every section in current README fits in the above order, so put them in another file @done
|
|
✔ CONTRIBUTING.md @done
|
|
✔ should include instructions for how to contribute to the project, including how to set up a development environment, run tests, and submit pull requests @done
|
|
✔ should include guidelines for code style and formatting and a hint, that vscode extensions are suggested from .vscode/extensions.json @done
|
|
✔ Not every section in current CONTRIBUTING.md fits in, so put them in another file @done
|
|
|
|
|
|
|
|
☐ Create `examples/` directory with runnable snippets
|
|
☐ Add comparison section vs. other TS pattern-matching libs in Readme.md
|
|
☐ Write migration guide for users coming from discriminated unions
|
|
☐ Create backlog tasks for implementation
|
|
☐ Validate code fences in Markdown (start with README.md) — compile the TypeScript examples against `src/` so the docs cannot drift from the API
|
|
|
|
Workflow:
|
|
☐ Resolve the finish/push tension: `create:finish` leaves `main` ahead of its upstream while `create:branch` refuses until `main` matches upstream — decide whether `finish` should push or `branch` should compare only `BEHIND` (see development/workflow.md)
|
|
|
|
Maintenance:
|
|
☐ Serve CI coverage over a tiny self-hosted webserver (replace the zip artifact) @low
|
|
✔ Add a minimal dir-listing webserver to the gitea docker setup (e.g. caddy `file_server browse` reusing the existing reverse proxy, or any single-binary static server, lipanski/docker-static-website) @done (9/13/2026, 9:02:37 PM)
|
|
✔ drop the `actions/upload-artifact` coverage step in favour of the shared-dir layout @done (9/13/2026, 10:37:22 PM)
|
|
☐ Explore serving coverage for non-tag pushes (e.g. `main/coverage`, PR previews) @low
|
|
✔ Manually verify the coverage was created on a real tag push (needs main) @low @done (9/14/2026, 1:55:03 PM)
|
|
→ design: no deploy step in CI; the webserver just exposes the shared directory (decided over Gitea Pages / Codecov — neither confirmed available/ wanted)
|
|
☐ serve docs over self hosted server @low
|
|
☐ Add a minimal dir-listing webserver to the gitea docker setup for serving docs (reuse existing reverse proxy)
|
|
☐ CI writes docs to a shared volume keyed by project + tag (e.g. `/docs/tiny-pattern-ts/<tag>/`)
|
|
☐ Browse to `…/docs/<repo>/<tag>/index.html` in the browser
|
|
☐ serve landing page over self hosted server @low
|
|
☐ Add a minimal dir-listing webserver to the gitea docker setup for serving landing page (reuse existing reverse proxy)
|
|
☐ CI writes landing page to a shared volume keyed by project + tag (e.g. `/landing/tiny-pattern-ts/<tag>/`)
|
|
☐ Browse to `…/tiny-pattern-ts/index.html` in the browser
|
|
✔ Stop Gitea CI re-downloading Node on every job @done
|
|
✔ Share the warm npm cache with the publish job @done
|
|
✔ Bake Node into the CI job image (docker/Dockerfile, container.image in ci.yml) @done
|
|
✔ Build/push gitea.e1nsnull.de/tmu/act-ci:26.8.2 and confirm setup-node skips the download @done
|
|
✔ Write the `<version>/x64.complete` marker — actions/tool-cache ignores a bare directory, so the probe missed and the download continued @done
|
|
✔ Log tool-cache state from the job container to find it (temporary, removed once understood) @done
|
|
✔ Guard the invariant in CI (`Assert the baked tool cache is present`) @done
|
|
✘ Enable force-pull for the runner so a changed act-ci image is never missed @low @cancelled
|
|
→ decided against: it is acceptable to miss a runner-side image change, and the image is only rebuilt on a Node bump, which changes the tag anyway. A Dockerfile-only change re-pushed under an unchanged tag is a known issue with a manual `docker rmi` workaround (see development/ci.md).
|
|
✔ Improve CI publish @done
|
|
✔ Check whether publish job is only run on tags, if not, guard it @done
|
|
✔ Gate only single steps @done
|
|
✔ Do not publish to npm, if NPM_TOKEN is not set (e.g. PRs from forks) @done
|
|
✔ Do not publish to Gitea — uses the run's automatic `github.token`, so no secret gate is needed @done
|
|
✔ Otherwise run the steps @done
|
|
✔ Fail the job unless both the Gitea release and npm publish succeeded @done
|