dextmorgn
88828c5f88
make lint was Python-only (PY_SRC never included flowsint-app) — frontend prettier/eslint lived solely in flowsint-app's own yarn scripts, disconnected from the repo's single lint entry point. Both are 0-errors clean today (eslint's ~130 findings are all warnings), same bar the Python side is already held to, so added as blocking rather than a separate opt-in step. CONTRIBUTING.md updated to match.
2.1 KiB
Contributing
Setup instructions live in the README. This file covers what to run before committing.
Before every commit
Run the checks for whatever you touched, not just the file you think is affected. mypy and eslint both regularly surface issues in neighboring files once you touch something they import.
Python (flowsint-core, flowsint-types, flowsint-enrichers, flowsint-api)
From the repo root:
make lint # ruff format --check + ruff check (whole repo) + frontend prettier/eslint check
make typecheck # mypy, ratcheted to files this branch touches vs origin/main
Then, for whichever package(s) you changed:
cd <package> && uv run pytest -q
make lint-fix applies ruff's safe autofixes, plus yarn format/yarn lint for the frontend, if make lint complains.
Frontend (flowsint-app)
make lint/make lint-fix from the repo root already cover prettier + eslint for flowsint-app. The rest, from flowsint-app/:
npx tsc --noEmit # types
npx vitest run # unit tests
yarn build # full build
What the pre-commit hook does for you
lint-staged runs automatically on git commit and handles:
**/*.py→ruff format+ruff check --fixflowsint-app/**/*.{ts,tsx,js,jsx}→prettier --write
It does not run mypy, eslint, or any test suite. Those are on you before pushing.
Why the ratchets
make typecheck and the frontend eslint CI job only gate files your branch actually changed, not the whole repo. Both codebases have a real pre-existing backlog (mypy: workspace-wide cross-package imports aren't fully typed yet; eslint: ~100 pre-existing no-explicit-any warnings). Gating everything from day one would make every unrelated PR red. Touch a file, and it's expected to pass strict checks; untouched files stay as they are until someone gets to them.
Commit style
Atomic commits please. one logical change per commit, not a single "fix everything" dump. Write commit messages that explain why, not just what changed line-by-line.