[CU-86b6u16q5] Add pyrefly type checking to development workflow

[philippasdev]

Integrate pyrefly static type checker into the development workflow
with both local make targets and CI automation.

Changes:

• Add pyrefly>=0.1.0 to dev dependency group in pyproject.toml
• Add 'make typecheck' target to run pyrefly check --summarize-errors
• Integrate 'pyrefly init' into 'make setup' workflow
• Create GitHub Actions workflow for automated type checking on PRs
• Update Makefile help text to include type checking commands

The pyrefly configuration in pyproject.toml excludes common non-code
directories (node_modules, pycache, venv)

Summary

This PR integrates Pyrefly static type checking into the DNAstack client library development workflow, enabling automated type error detection during development and CI.

What is Pyrefly?

Pyrefly is a fast type checker and language server for Python that helps catch type-related bugs before runtime. It improves code quality through type annotations that serve as living documentation and enables safer refactoring.

Changes

Development Dependencies

• Added pyrefly>=0.1.0 to the dev dependency group in pyproject.toml
• Configured pyrefly to exclude common non-code directories (node_modules, __pycache__, *venv)

Local Development

• New Make target: make typecheck - Runs pyrefly check --summarize-errors for local type checking
• Setup integration: make setup now includes pyrefly init to initialize the type checker
• Updated help documentation: Added "Linting & Type Checking" section to make help

CI/CD

• New GitHub Actions workflow: .github/workflows/typecheck.yml
  • Triggers on pull requests to main branch
  • Manual triggering via workflow_dispatch
  • Uses pinned action versions for security (matching existing workflows)
  • Leverages uv caching for fast builds
  • Runs make typecheck for consistency with local development

Benefits

• Catch bugs early: Identify type-related errors during development rather than at runtime
• Improve code quality: Type annotations serve as living documentation
• Safer refactoring: Type checking ensures changes don't introduce type mismatches
• Better IDE support: Enhanced autocomplete and refactoring tools
• Team collaboration: Clearer contracts between functions and modules

Usage

Local Development

# Run type checking
make typecheck

# Setup includes pyrefly initialization
make setup

Pre-commit Workflow

# Recommended checks before committing
make lint && make test-unit && make typecheck

CI Integration

Type checking runs automatically on all pull requests to main and can be manually triggered via the GitHub Actions UI.

Documentation

- Pyrefly Documentation: https://pyrefly.org/en/docs/
- Installation Guide: https://pyrefly.org/en/docs/installation/

Test plan

- Run make setup to verify pyrefly initialization works
- Run make typecheck to verify type checking executes successfully
- Verify GitHub Actions workflow runs on PR creation
- Check that make help displays the new typecheck command
- Confirm pyrefly is installed as part of dev dependencies via uv sync --group dev

[platform-automation-dnastack]

Task linked: CU-86b6u16q5 dnastack-client: Update questions ask command --collections parameter to support HTTPie-style file parsing

[github-actions]

☂️ Python Coverage

current status: ✅

Overall Coverage

Lines	Covered	Coverage	Threshold	Status
10407	5700	55%	30%	🟢

New Files

No new covered files...

Modified Files

No covered modified files...

updated for commit: 3307013 by action🐍

To fix this issue, we need to add a permissions: block to the workflow YAML file, specifying the minimum required permissions for the GITHUB_TOKEN. Because the workflow only performs read-only operations, the lowest practical permission is to set contents: read either at the workflow root or at the job level. It is best practice to place it at the workflow root so all jobs in this workflow inherit the reduced permission unless they explicitly override it. The change should be made in .github/workflows/typecheck.yml by inserting a block like:

permissions:
  contents: read

directly after the name: declaration (or above the first on: block for clarity), ensuring that only read access to repository contents is granted for all jobs in the workflow.