Skip to content

fix: fix eslint-disable block range not working correctly#500

Merged
fansenze merged 1 commit intomainfrom
fix/disable-comment-block-range-20260310
Mar 11, 2026
Merged

fix: fix eslint-disable block range not working correctly#500
fansenze merged 1 commit intomainfrom
fix/disable-comment-block-range-20260310

Conversation

@fansenze
Copy link
Copy Markdown
Contributor

@fansenze fansenze commented Mar 10, 2026

Summary

Fix DisableManager block-level eslint-disable / eslint-enable ranges not working correctly.

Root cause: The previous implementation used a flat map[string]bool to store disable state. It only recorded the final state after processing all directive comments, so range-based disable/enable was broken — once a rule was re-enabled via eslint-enable, the earlier disable range was lost.

Fix: Replace the map-based model with an event-based blockDirectives model. The isBlockDisabled() method replays directives in source order to correctly determine whether a rule is disabled at any given line.

Previously broken cases now fixed:

  1. eslint-disable + eslint-enable block range — diagnostics inside the range were not suppressed
  2. Multiple disable/enable ranges in a single file — only the last range's state was retained
  3. Wildcard eslint-disable + specific rule eslint-enable — re-enabling a specific rule didn't work while keeping others disabled
  4. eslint-disable without eslint-enable — disable to end-of-file didn't work correctly when combined with other directives

Already working (unchanged):

  • eslint-disable-next-line (line-level)
  • eslint-disable-line (inline)
  • Wildcard variants of line-level directives
  • Block comment style (/* ... */) for all directive types

Related Links

N/A

Checklist

  • Tests updated (or not required).
  • Documentation updated (or not required).

@fansenze
fix: fix eslint-disable block range not working correctly
ddece9d 
The DisableManager used a flat map to store disable state, which only
recorded the final state after processing all comments. This caused
eslint-disable/eslint-enable block ranges to not work — once a rule
was re-enabled, the disable range before it was lost.

Replace the map-based model with an event-based blockDirectives model.
The isBlockDisabled() method replays directives in source order to
correctly determine whether a rule is disabled at any given line.
@fansenze fansenze force-pushed the fix/disable-comment-block-range-20260310 branch from fc12f3e to ddece9d Compare March 10, 2026 11:22
@gemini-code-assist
Copy link
Copy Markdown

gemini-code-assist bot commented Mar 10, 2026

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly improves the accuracy and reliability of ESLint-style disable and enable comment directives, particularly for block-level ranges. By transitioning from a state-based map to an event-replay model, the system can now correctly interpret and apply disable/enable directives across multiple lines and complex scenarios, ensuring that linting rules are suppressed precisely as intended by the developer.

Highlights

  • Refactored Block-Level ESLint Directive Handling: The core logic for eslint-disable and eslint-enable block comments has been completely rewritten. Previously, a simple map (disabledRules) stored the final state, leading to incorrect behavior for ranges. The new approach uses an event-based blockDirectives model, replaying directives in source order to accurately determine rule disablement at any given line.
  • Fixed Range-Based Disable/Enable Issues: This change resolves several long-standing bugs, including diagnostics not being suppressed within eslint-disable / eslint-enable block ranges, incorrect state retention with multiple disable/enable ranges, and issues with wildcard disables combined with specific rule re-enabling.
  • Enhanced Test Coverage: Extensive new unit tests have been added for the isBlockDisabled algorithm, covering various scenarios like basic disable/enable, multiple ranges, wildcard interactions, and edge cases. Additionally, new CLI integration tests validate the end-to-end functionality of eslint-disable comment directives.
Changelog
  • internal/rule/disable_manager.go
    • Removed ESLintDirective struct and ESLintDirectiveKind enum.
    • Introduced blockDirective struct to represent block-level disable/enable events.
    • Replaced disabledRules map with blockDirectives slice in DisableManager.
    • Updated NewDisableManager to initialize blockDirectives instead of disabledRules.
    • Renamed parseESLintDirectives to parseDirectives and adjusted its internal logic.
    • Modified parseDirectives to record block eslint-disable and eslint-enable directives as blockDirective entries.
    • Added strings.TrimSpace to parseRuleNames for robust parsing.
    • Updated IsRuleDisabled to leverage the new isBlockDisabled method for block-level checks.
    • Implemented isBlockDisabled method, which replays block directives in source order to determine rule disablement at a specific line.
  • internal/rule/disable_manager_test.go
    • Removed unused regexp and strings imports.
    • Expanded TestParseRuleNames with more comprehensive test cases.
    • Removed outdated TestESLintDirectiveRegexPatterns and TestDisableManagerBasicFunctionality.
    • Added TestIsBlockDisabled with extensive unit tests for the new block directive logic, covering various scenarios.
    • Introduced TestDisableManagerLineLevelDirectives to maintain coverage for line-level directives.
    • Added isLineDisabled helper method for isolated line-level directive testing.
    • Included TestDisableManagerBlockAndLineCombined for integration testing of block and line directives.
  • packages/rslint-test-tools/rstest.config.mts
    • Added disable-comments.test.ts to the CLI test suite configuration.
  • packages/rslint-test-tools/tests/cli/disable-comments.test.ts
    • Added new CLI integration test file for eslint-disable comment directives.
    • Implemented tests for eslint-disable-next-line, eslint-disable-line, and eslint-disable / eslint-enable block ranges.
    • Included tests for wildcard directives, block comment style for line directives, and multiple disable/enable ranges.
    • Provided utility functions (runRslint, createTempDir, cleanupTempDir, makeConfig) for robust CLI testing.
Using Gemini Code Assist

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.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist[bot]
gemini-code-assist bot reviewed Mar 10, 2026
View reviewed changes
Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request provides a solid fix for handling eslint-disable block ranges by moving from a stateful map to an event-based model. The new implementation correctly replays directives to determine the disable status at any given line, resolving several bugs with block-level comments. The logic is sound and is well-supported by a comprehensive new suite of unit and integration tests, which gives high confidence in the correctness of the fix. I have one minor suggestion for a performance improvement.

@fansenze fansenze merged commit ff4e96f into main Mar 11, 2026
14 checks passed
@fansenze fansenze deleted the fix/disable-comment-block-range-20260310 branch March 11, 2026 03:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@hardfist hardfist hardfist approved these changes

+1 more reviewer

@gemini-code-assist gemini-code-assist[bot] gemini-code-assist[bot] left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

release: bug fix

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@fansenze @hardfist