build(deps): bump djangorestframework-stubs from 1.8.0 to 3.16.6

[dependabot]

Bumps djangorestframework-stubs from 1.8.0 to 3.16.6.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[claude]

Pull Request Review: djangorestframework-stubs 1.8.0 → 3.16.6

Overview

This is a Dependabot-initiated upgrade of djangorestframework-stubs from 1.8.0 to 3.16.6 (a major version bump spanning ~2 years of development). This is a development dependency for type checking with mypy and does not affect runtime behavior.

---

✅ Positive Aspects

1. Long-overdue update: The current version (1.8.0) is severely outdated. This brings improved type coverage and fixes for Django REST Framework.

2. Proper dependency scope: This is a local/dev requirement only (requirements/local.txt), so production deployments are unaffected.

3. Compatibility alignment: Your project uses:

   • djangorestframework==3.16.1 (base.txt:40)
   • django-stubs==4.2.7 (local.txt:12)
   • mypy==1.18.2 (local.txt:11)

   The new stubs version (3.16.6) is designed to match DRF 3.16.x, so this upgrade improves type-checking accuracy.

---

⚠️ Concerns & Recommendations

1. Major Version Jump Risk

Risk Level: MEDIUM

A jump from 1.8.0 to 3.16.6 spans multiple major versions. The djangorestframework-stubs project follows semantic versioning for breaking changes in type annotations, which could cause:

• New mypy errors/warnings in existing code
• Changed type signatures requiring code adjustments
• Plugin behavior changes affecting type inference

Recommendation: Run mypy across the entire codebase before merging:

docker compose -f local.yml run django mypy opencontractserver config

2. Mypy Plugin Configuration

Location: setup.cfg:40

Your mypy config uses:

[mypy]
plugins = mypy_django_plugin.main, mypy_drf_plugin.main

The mypy_drf_plugin.main plugin is provided by djangorestframework-stubs. A major version upgrade may have changed plugin behavior or requirements.

Recommendation: Verify the plugin still loads correctly by running:

docker compose -f local.yml run django mypy --version
docker compose -f local.yml run django mypy --config-file=setup.cfg --show-plugins

3. Limited DRF Usage = Lower Risk

Observation: Based on code analysis, DRF usage is minimal:

• opencontractserver/users/api/serializers.py (simple ModelSerializer)
• GraphQL endpoints (primary API pattern)
• A few analyzer views

Since this is primarily a GraphQL-based API (Graphene), the impact surface is small, which reduces risk.

4. Test Coverage Gaps

Gap: No type-checking validation in CI/CD pipeline

Your test suite includes:

• Backend tests (pytest, django TestCase)
• Frontend tests (Vitest, Playwright)
• Pre-commit hooks (black, isort, flake8)

Missing: Automated mypy checks in CI/CD

Recommendation: Consider adding mypy to your CI/CD pipeline or pre-commit hooks to catch type errors automatically:

# .pre-commit-config.yaml
- repo: https://github.com/pre-commit/mirrors-mypy
  rev: v1.18.2
  hooks:
    - id: mypy
      additional_dependencies: [django-stubs==4.2.7, djangorestframework-stubs==3.16.6]

---

🔒 Security Assessment

Status: ✅ NO CONCERNS

• This is a type-checking tool (no runtime execution)
• Does not process user input or network data
• Cannot introduce runtime vulnerabilities
• Dependabot security badge shows no known vulnerabilities

---

📋 Action Items Before Merge

1. CRITICAL: Run mypy to check for new type errors:

   docker compose -f local.yml run django mypy opencontractserver config

2. Recommended: Verify plugin compatibility:

   docker compose -f local.yml run django mypy --show-plugins

3. Recommended: Run backend tests to ensure no unexpected side effects:

   docker compose -f test.yml run django pytest -n auto --dist loadscope

4. Optional: Update CHANGELOG.md if this reveals and fixes type-checking issues:

   ### Changed
   - Updated djangorestframework-stubs from 1.8.0 to 3.16.6 for improved type coverage (`requirements/local.txt:17`)

---

🎯 Final Recommendation

APPROVE WITH CONDITIONS: This upgrade is beneficial and low-risk, but should be validated with mypy before merging.

If mypy passes cleanly: ✅ Safe to merge immediately
If mypy reports new errors: Review each error to determine if it is:

• A false positive (suppress with # type: ignore[error-code])
• A legitimate type issue (fix the code)
• A plugin incompatibility (may need django-stubs upgrade too)

---

📚 Additional Context

According to your CLAUDE.md:

Always ensure all affected (or new) tests pass - backend tests suite should only be run in its entirety for good reason as it takes 30+ minutes.

Since this is a dev-only dependency change with minimal DRF usage, running targeted mypy checks is more efficient than the full test suite. However, if mypy reveals issues requiring code changes, run affected tests accordingly.

Estimated impact: LOW (affects <10 files based on DRF usage patterns)

[claude]

PR Review: Dependency Update - djangorestframework-stubs

Summary

This PR updates djangorestframework-stubs from version 1.8.0 to 3.16.6 (a major version bump spanning 2 major versions). This is a type stub package for Django REST Framework used by mypy for static type checking.

---

Code Quality & Best Practices ✅

Positive:

• Automated dependency update via Dependabot
• Single-file change in dev dependencies (requirements/local.txt)
• Aligns with DRF version 3.16.1 currently in use (base.txt:40)

Concerns:

• ⚠️ Major version jump (1.x → 3.x) typically indicates breaking changes in type annotations
• The package versioning now matches the DRF version it supports (3.16.x), which is good for compatibility

---

Compatibility Analysis 🔍

Environment Configuration:

• Project uses mypy with mypy_drf_plugin.main plugin (setup.cfg:40)
• Current DRF version: 3.16.1 (requirements/base.txt:40)
• Current django-stubs version: 4.2.7 (requirements/local.txt:12)
• Python version: 3.9 (setup.cfg:34)

DRF Usage in Codebase:
The codebase has limited DRF usage (6 files):

• opencontractserver/users/api/serializers.py
• opencontractserver/analyzer/views.py
• 4 test files

This limited scope reduces the risk of type checking regressions.

---

Recommendations 📋

Before Merging:

1. Run mypy type checking to ensure no new type errors:

   docker compose -f local.yml run django mypy opencontractserver/

2. Run the test suite (as per CLAUDE.md):

   # Parallel tests (recommended)
   docker compose -f test.yml run django pytest -n 4 --dist loadscope

3. Check pre-commit hooks pass:

   pre-commit run --all-files

Expected Outcome:

• ✅ Mypy should pass without new errors (or have improved type coverage)
• ✅ Tests should pass (this is a dev-only dependency)
• ✅ Pre-commit hooks should pass

---

Security Considerations 🔒

• ✅ No security concerns - this is a development-only type stub package
• ✅ No runtime impact (type stubs are used only during static analysis)

---

Performance Considerations ⚡

• ✅ No performance impact - dev dependency only, not included in production

---

Test Coverage 📊

• ✅ Existing test suite should be sufficient (type stubs don't require new tests)
• ⚠️ Action Required: Verify mypy type checking passes to ensure the updated stubs don't introduce type errors

---

Final Verdict

Conditional Approval ✅ pending CI validation

This is a standard dependency update with low risk, but the major version jump requires verification:

1. ✅ Aligns stub version with actual DRF version (good practice)
2. ✅ Limited DRF usage in codebase reduces risk
3. ⚠️ Requires CI validation to confirm no type checking regressions
4. ✅ No runtime or security impact

Next Steps:

• Wait for CI checks to complete
• Review any mypy errors that may surface
• If CI passes, this is safe to merge

---

Review conducted according to repository CLAUDE.md guidelines

[claude]

PR Review: Dependency Update - djangorestframework-stubs 1.8.0 → 3.16.6

Summary

This PR bumps djangorestframework-stubs from version 1.8.0 to 3.16.6 - a major version jump (from v1 to v3) that spans approximately 2+ years of development.

Analysis

Compatibility Check:

• ✅ Django REST Framework version: 3.16.1 (compatible)
• ✅ django-stubs version: 4.2.7 (compatible)
• ✅ mypy version: 1.18.2 (compatible)
• ✅ mypy plugin configured in setup.cfg:40: mypy_drf_plugin.main

Code Impact:
The project uses DRF in several areas:

• Serializers in config/graphql/serializers.py and config/graphql/annotation_serializers.py
• User API serializers
• Authentication backends
• Multiple test files

Concerns & Recommendations

⚠️ Major Version Jump Risks:

1. Breaking Changes: A jump from v1.8.0 to v3.16.6 likely includes breaking changes in type definitions. Common issues with stub updates include:

   • Changed generic type parameters (e.g., Serializer[Model] → different signature)
   • Stricter type checking that may reveal previously hidden type issues
   • Method signature changes in stubs

2. Type Checking Required: Before merging, you should:

   # Run mypy to catch any new type errors
   docker compose -f local.yml run django mypy opencontractserver config

3. Pre-commit Hooks: Ensure pre-commit passes:

   pre-commit run --all-files

✅ Positive Notes:

• This is a development dependency (requirements/local.txt), so it won't affect production runtime
• Newer stubs typically provide better type coverage and catch more bugs
• The project already has mypy configured with the DRF plugin, so integration is established

Testing Recommendations

Per CLAUDE.md guidelines:

1. Run backend tests (especially those using DRF serializers):

   docker compose -f test.yml run django pytest -n 4 --dist loadscope

2. Run mypy type checking to catch any new type errors introduced by stricter stubs

3. Verify pre-commit hooks pass

Verdict

CONDITIONAL APPROVAL - This dependency update is reasonable, but should only be merged after:

1. CI passes (especially type checking)
2. Manual verification that mypy runs without new errors
3. Backend test suite passes

The age of the current version (1.8.0) and the size of this jump warrant caution, but as a dev-only dependency, the risk is limited to developer experience rather than production stability.

---

Note: If mypy reveals new type errors, they should be addressed before merging. These would represent actual type safety improvements, not regressions.