• internal/config/config.go
  • Added import for the new prefer_readonly rule.
  • Registered the @typescript-eslint/prefer-readonly rule in the global rule registry.
• internal/linter/linter.go
  • Implemented the ReportRangeWithFixes function within the linter's RunLinterInProgram to handle range-based fix reporting from rules.
• internal/plugins/typescript/rules/prefer_readonly/prefer_readonly.go
  • New file: Implements the core logic for the prefer-readonly rule.
  • Includes functions for parsing rule options, managing class scopes, tracking variable modifications, and determining type relations.
  • Provides helper functions for AST node manipulation and type checking.
  • Defines the PreferReadonlyRule with listeners for class declarations, expressions, constructors, and function scopes to detect violations.
  • Implements reportViolations and buildFixes to generate diagnostics and autofixes, including type widening for literal types.
• internal/plugins/typescript/rules/prefer_readonly/prefer_readonly_test.go
  • New file: Contains extensive Go-based unit tests for the prefer-readonly rule.
  • Includes 28 valid test cases covering already readonly members, modified members, destructuring, increment/decrement, accessors, intersection/union types, and nested classes.
  • Includes 20 invalid test cases covering private static/instance members, private fields, constructor parameters, onlyInlineLambdas option, literal type widening, type annotations, overlapping classes, optional chaining, and non-null assertions, all with expected autofix outputs.
• internal/rule/rule.go
  • Added ReportRangeWithFixes field to the RuleContext struct, providing a new method for rules to report diagnostics with associated fixes for a specific text range.
• packages/rslint-test-tools/rstest.config.mts
  • Uncommented the entry for ./tests/typescript-eslint/rules/prefer-readonly.test.ts to enable JavaScript integration tests for the new rule.

• The pull request introduces a new linter rule, prefer-readonly, for TypeScript.
• The rule's implementation and its comprehensive Go test suite have been added.
• Changes were made to the core linter and rule context to support range-based autofix reporting.
• The rstest.config.mts file was updated to include the new rule in the JavaScript integration tests.
• The PR description indicates that the code was generated with Claude Code.

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.