fireproof icon indicating copy to clipboard operation
fireproof copied to clipboard

Upgrade to type-checked ESLint rules (demonstrates scope of PR 465)

Open jchris opened this issue 3 months ago • 2 comments

Summary

  • Upgrades ESLint configuration from basic strict/stylistic rules to type-checked rules
  • Demonstrates the massive scope of cleanup needed for stricter type checking
  • Exposes 2,304 lint violations that need to be addressed

Changes

  • eslint.config.mjs: Switch to strictTypeChecked, stylisticTypeChecked, recommendedTypeChecked
  • Added TypeScript project configuration for type-aware linting
  • Added @typescript-eslint/prefer-readonly rule

Test Results

Running pnpm lint after this change reveals 2,304 errors including:

  • @typescript-eslint/no-unsafe-assignment - lots of any type issues
  • @typescript-eslint/no-unsafe-member-access - unsafe property access
  • @typescript-eslint/prefer-nullish-coalescing - using || instead of ??
  • @typescript-eslint/prefer-readonly - class members that should be readonly
  • @typescript-eslint/require-await - async functions without await
  • Plus many more strict typing violations

Context

This PR demonstrates that PR #465 is essentially just the ESLint config upgrade plus the massive cleanup of all resulting violations. The "real" change is this config file - everything else in #465 is cleanup.

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Chores
    • Upgraded linting configuration to use type-aware rules for TypeScript, improving static analysis and code consistency.
    • Refined ignore patterns and introduced targeted per-file overrides to streamline developer workflow and reduce false positives.
    • No user-facing changes; application behavior remains unchanged.

jchris avatar Sep 17 '25 18:09 jchris

Note for potential contributors: This would actually be an excellent way for a new contributor to learn the Fireproof codebase!

Working through these 2,304 lint violations would require:

  • Reading and understanding code across the entire project
  • Learning the type system and architecture
  • Making systematic improvements to type safety
  • Getting familiar with the build tools and development workflow

Each fix is relatively small and focused, but collectively they'd give you deep familiarity with how Fireproof works internally. Plus you'd be making a real contribution to code quality and maintainability.

If anyone is interested in taking this on (either the whole thing or chunks of it), it would be very welcome! 🙏

jchris avatar Sep 17 '25 18:09 jchris

Walkthrough

Replaced ESLint base presets with TypeScript type-checked variants, updated language options to use parserOptions with project-based type info, revised ignore patterns, and added per-file overrides for JS and TS/TSX (including a new readonly rule for TS). Existing export default options remain unchanged.

Changes

Cohort / File(s) Change summary
ESLint config modernization
eslint.config.mjs
Switched to strictTypeChecked/stylisticTypeChecked/recommendedTypeChecked; set parserOptions (sourceType: module, project, tsconfigRootDir); adjusted ignores (added dist/**, coverage/, etc.; removed cache-related patterns); per-file overrides: JS uses disableTypeChecked, TS enforces @typescript-eslint/prefer-readonly; preserved export default opts.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title "Upgrade to type-checked ESLint rules (demonstrates scope of PR 465)" directly describes the primary change (switching to type-checked ESLint rules) and adds brief contextual scope, matching the modifications in eslint.config.mjs and the PR objectives; it is concise, specific, and not noisy. The parenthetical note about PR 465 provides useful context without obscuring the main intent. Overall the title would be clear to a reviewer scanning the repository history.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.
✨ Finishing touches
  • [ ] 📝 Generate Docstrings
🧪 Generate unit tests
  • [ ] Create PR with unit tests
  • [ ] Post copyable unit tests in a comment
  • [ ] Commit unit tests in branch jchris/test-strict-eslint

[!TIP]

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

  • Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
  • Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

coderabbitai[bot] avatar Sep 17 '25 18:09 coderabbitai[bot]