Tracking: gradual introduction of ty type checking

[filiplajszczak]

What is the problem or limitation you are having?

There is no type checking in the project. Type errors are caught only at runtime or during review. Previous discussion (#665) concluded that mypy was too slow and annotations weren't an inherent good. ty changes the equation — it checks all of src/briefcase/ in ~0.16s.

See Type checking with ty (discussion) for background.

Describe the solution you'd like

Gradually introduce ty type checking, module by module, without disrupting existing workflows.

Current state:

• 597 diagnostics on src/briefcase/ with ty 0.0.18
• Many are unresolved-attribute from dynamic attribute access on BaseConfig/AppConfig
• ~60% of files already have from __future__ import annotations
• Newer code (channels, integrations, debuggers) already uses Protocols and annotations

Roadmap:

• Add ty as non-blocking CI check #2710 (tox env + pyproject.toml config, pinned version)
• Let ty see BaseCommand attributes on platform mixins #2734
• Platform-specific AppConfig attributes are invisible to type checkers #2739
• Fix invalid dict[str, ...] type annotations. #2800
• Review remaining 192 non-attribute diagnostics for real catches
• Identify first module(s) to enforce (e.g. channels/, integrations/base.py)
• Expand enforcement module by module

Describe alternatives you've considered

• mypy: too slow for pre-commit/CI integration, heavier configuration burden
• pyright: faster than mypy but still heavier than ty; not part of the existing Astral toolchain
• Do nothing: viable, but misses real catches (e.g. functions with implicit None returns typed as -> bool)

Additional context

Principles agreed on in the discussion:

• ty adapts to the codebase, not the other way around
• Non-blocking until a module is explicitly opted in
• Pin ty version, upgrade deliberately
• Dynamic attributes are intentional. Platform modules may stay excluded or warn-only long-term

[xyaz1313]

Hey, I'd like to work on this. I have experience with Python web development and have worked with similar frameworks before. Happy to start right away.

[freakboy3742]

@xyaz1313 Go right ahead! We don't formally assign issues; letting us know that you're interested in a topic is enough for us.

As the ticket notes, some of this work has already been done (so ty is in place, and we've done some of the refactoring); if there's anything big is needed to accomodate stronger type checks, it would be worth bouncing your ideas off us before you go too deep down an implementation rabbit hole.