86 lines
6.1 KiB
Plaintext
86 lines
6.1 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
|
|
☐ Review existing documentation for accuracy and completeness
|
|
☐ README.md should be the main entry point for users, and CONTRIBUTING.md should be the main entry point for contributors
|
|
☐ A lot of decisions are documented in the current README.md and CONTRIBUTING.md, that are not part of a main entry for users, how to use the library nor part of a main entry for contributors,
|
|
☐ evaluate a new structure for the docs, and move the relevant information to the new docs
|
|
☐ have a look at other well known repositories for inspiration on how to structure the docs
|
|
☐ 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
|
|
☐ More important is to have the documentation of our decisions, shortcomings and known issues, not sure where to put this. at work we have ADRs, maybe that? Please suggest something after having looked at other well known repos
|
|
☐ make sure to preserve that information in the new docs
|
|
☐ README.md
|
|
☐ I really like the order perl documentation does it: name with a single line description, version, Synopsis, Description, examples, API reference, license
|
|
(example: https://metacpan.org/pod/Scalar::Util)
|
|
☐ should include a clear description of the library, its purpose, and how to use it
|
|
☐ Add usage examples to README.md
|
|
☐ version needs to be kept in sync with package.json in release.sh
|
|
☐ Not every section in current README fits in the above order, so put them in another file
|
|
☐ CONTRIBUTING.md
|
|
☐ should include instructions for how to contribute to the project, including how to set up a development environment, run tests, and submit pull requests
|
|
☐ should include guidelines for code style and formatting and a hint, that vscode extensions are suggested from .vscode/extensions.json
|
|
☐ Not every section in current CONTRIBUTING.md fits in, so put them in another file
|
|
|
|
|
|
|
|
☐ 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
|
|
|
|
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 CONTRIBUTING § CI runner image).
|
|
✔ 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
|