ops: wire frontend into shared task infrastructure (#269)#271
ops: wire frontend into shared task infrastructure (#269)#271edvardm wants to merge 34 commits intoOpenFilamentCollective:mainfrom
Conversation
- add .setup-webui and .install-playwright with sentinel-based skipping so pnpm install and browser downloads are skipped when already up to date - setup, test, lint, check now delegate to both Python and WebUI - check delegates to lint and test to avoid duplicating commands - add webui (dev server) and webui-build tasks - remove internal: true from setup tasks so they can be run directly
Developer setup docs covering prerequisites (uv, pnpm, task), bootstrap via task setup, and key commands. README links to it from the install requirements step.
pnpm offers stricter dependency isolation (no phantom deps) and a content-addressable store. Sets pnpm >=10 lower bound via engines field. - replace package-lock.json with pnpm-lock.yaml - add engines.pnpm >=10 to package.json - update playwright.config.js webServer command to use pnpm - rename webui-tests.yml -> frontend-tests.yml and switch to pnpm
|
Hi there @edvardm thanks a lot! I'll let @coffandro take charge here, i am wondering if we prefer Bun over PNPM though? Edit: as a side note we might have pointed to NPM as an easy to use beginner friendly tool so less technically minded people could get started, i believe Bun also has an easy install path, not sure about pnpm, but i am sure that is not a concern. |
pnpm/action-setup@v4 requires either a version input or packageManager in package.json. Use version: latest to avoid pinning.
|
I've started to use bun myself when working with FE stuff, so super happy to. I was even thinking of abstracting the tool to use so that devs could choose it, but as they don't use same files I guess that would be extraneous complexity for no reason. My only small gripe with bun is that IIRC pnpm is a bit better for security-oriented setups, but of course it always depends on the context. So, would I revise the plan and PR to use bun instead of pnpm? Nice thing with task automation is that it does abstract details like this, in that sense adding taskfile to even frontend could be useful (use 'task dev' to start webui, no need to care what package manager is used). But then again it's extra layer to maintain etc :P |
Tests cover UUID generation (spec-defined deterministic values), slugify, normalize_color_hex, and ensure_list — all pure functions in ofd/builder/utils.py. Intended as style reference for future tests.
- Remove module docstring and inline comments - Drop redundant determinism and "names differ" UUID tests - Move uuid import to top level - Use parametrize for slugify and normalize_color_hex - Update testing-guidelines skill: clarify explicit loops are banned, parametrize is recommended
Separate parametrized groups for: normal normalization cases, list input, empty/None inputs, and unparseable passthrough.
|
Even with bun the default behavior of using something like bun run / bunx is to invoke nodejs as the default runtime anyhow. The advantage i like is the package manager is really good, fast and efficient compared to npm, but even pnpm at times. So usually I'd have nodejs installed on the system, then use bun as the entrypoint/package manager, which functions nicely like uv might. But as long as the CI can have dep-caching then either solution is fine. As you mentioned the process is entirely opague from the invoker, perhaps making package install generic so bun could be used in CI just for the perf? |
|
While we are at it, we should enforce conventionalcommits.org at CI time and pre-commit time. If out of scope of this PR, we'll do it seperately. |
|
just learned there's this new https://github.com/j178/prek which is already getting lots of traction, basically Rust rewrite of pre-commit making it much faster -- just an idea, but to try it out I initially added configuration for that in this repo, very basic stuff, as recommended by Astral software. But yeah, separate PR to address that is better |
|
Re bun vs pnpm, I'd suggest to keep this more contained we'll just use bun and afterwards see if abstracting FE package manager with taskfile or similar would make sense? It's simple, but adds at least moderate friction probably for some. I'll add single commit which switches to bun, the whole change affects only 5 files and is pretty isolated, easy to revert if desired. Edit: even better, let's stick to npm for now as suggested by @cjavad and address pkg manager switch in another PR if desired |
|
Lets perhaps keep npm for this PR then if possible? |
|
Tbh, I would prefer if we keep to using stock NPM with maybe support for bun for power users? The goals of the webui require most people to be able to just run for users who aren't technical so every installation step we'll have to cover in our documentation will hurt our adoption. |
0e17ce9 to
f0a0b1c
Compare
|
Forgot to push, PR should now have less changes and use npm. I fully agree with both; would be outside the scope for this, and in any case should be discussed separately |
Rename .github/workflows/frontend-tests.yml to webui-tests.yml and restore content to match main exactly: workflow name "WebUI Tests", job id test-webui, npm cache config, and build step included.
Add validate as a dep to the check task so it covers lint, data validation, and all tests in one command. Reference task check in a new "Making a PR" section that also encourages single-logical-change PRs.
Why: avoid duplicating the pytest invocation already defined in `test`; aggregate tasks should reuse existing rules.
|
I'm happy with current changes finally, I can trim it down further if desired |
There was a problem hiding this comment.
Pull request overview
This PR wires the WebUI into the shared Taskfile-based developer workflow, adds initial Python unit tests for utility functions, and introduces a dedicated GitHub Actions workflow for running pytest on PRs.
Changes:
- Expanded
Taskfile.ymlto cover Python + WebUI setup/lint/test flows (including Playwright install and WebUI build/dev tasks). - Added
tests/test_utils.pyand removed the placeholdertests/test_dummy.py. - Migrated dev tooling dependencies to PEP 735 dependency groups and added a
pytest.ymlCI workflow; added developer setup docs (CONTRIBUTING.md) and linked them fromREADME.md.
Reviewed changes
Copilot reviewed 7 out of 9 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
uv.lock |
Reflects the dev-dependency metadata changes associated with the dependency group migration. |
tests/test_utils.py |
Adds pytest coverage for UUID derivation, slugification, color normalization, and list normalization utilities. |
tests/test_dummy.py |
Removes placeholder test now that real tests exist. |
Taskfile.yml |
Unifies setup/lint/test/check across Python + WebUI and adds WebUI-specific tasks and sentinels. |
README.md |
Links developers to CONTRIBUTING.md. |
pyproject.toml |
Moves dev tooling deps to [dependency-groups] (PEP 735). |
CONTRIBUTING.md |
Adds developer setup and common Taskfile/npm workflows documentation. |
.gitignore |
Ignores local Taskfile directory and Python coverage outputs. |
.github/workflows/pytest.yml |
Adds CI job to run Python tests via task test. |
|
LGTM assuming those issues are fixed, |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Partially addresses #269
What's changed
Taskfile
setup,lint, andchecknow cover both Python and WebUI.checkdepends onlint,validate, andtest-all.testruns Python (pytest) only;test-alladds WebUI Playwright tests on top viadeps: [test].webui(dev server) andwebui-buildtasks.npm installand Playwright browser downloads are skipped when already up to date.local/Taskfile.ymlis gitignored and optionally included — useful for personal tasks not meant for version control.Tests
tests/test_utils.py).test_dummy.py.[project.optional-dependencies]to[dependency-groups](PEP 735).CI
pytest.ymlGitHub Actions workflow to run Python tests on PRs.CONTRIBUTING.md
task setup, and key commands. Linked from README.task checkto the pre-PR checklist.Frontend devs can still work directly in
webui/with npm — no need to installtask.