Modernize project configuration and development tooling - #70
Conversation
Run the frontend-installed Biome migration explicitly against the root and frontend configuration files so dependency updates cannot leave either versioned schema stale.
Enforce the npm install-script allowlist across local, CI, update, and Docker installs. Validate Python, Node.js, and npm before setup mutates the virtual environment or Git hooks.
Pass the strict install-script policy at each npm dependency command in local setup, maintenance, CI, and Docker. Remove the extra npm configuration layer in favor of visible CLI enforcement.
Derive the isolated mypy hook's runtime and type-stub dependencies from pyproject.toml during dependency maintenance, preventing the duplicated prek list from drifting.
Move frontend-specific Biome rules into the root configuration, point frontend scripts at the shared file, and migrate only that single configuration during dependency updates.
|
Hey @Snuffy2 , I haven't had a chance to review this yet, but I plan to. I'm rebuilding my main PC but hopefully I can get to it soon. |
|
Hi @Snuffy2 , Thanks for the contribution — this is a lot of solid work. I'm good with pretty much all of it minus one thing: would you mind taking another look at I'm fine with automation that only runs when someone actually pushes or opens something — a human's in the loop at that point. This one also runs on its own every day via cron, and it's calling an action out of your personal GitHub, not an established publisher, with write access to the repo. Nothing against the action itself, it's more that I'd be handing out unattended, permanent write access to something with no established track record yet. |
|
I pulled |
2 participants
Summary
Modernizes MouseTrap's project configuration and development tooling so local setup, CI, dependency maintenance, and Docker builds use the same supported Python, Node.js, npm, Biome, and prek contracts.
What Changed
pyproject.tomland replaced the legacy pre-commit configuration withprek.toml.Why
The repository previously spread overlapping configuration across several files and allowed local, CI, and Docker workflows to drift. Centralizing the authoritative settings and enforcing the same dependency-install policies makes maintenance simpler and ensures unsupported or unapproved tooling fails early.