Skip to content

fix(rules): do not hardcode js extensions in apply_centralized_exclusions - #70

Open
Adityakk9031 wants to merge 1 commit into
Corgea:mainfrom
Adityakk9031:fix/rules-centralized-exclusions-extensions
Open

fix(rules): do not hardcode js extensions in apply_centralized_exclusions#70
Adityakk9031 wants to merge 1 commit into
Corgea:mainfrom
Adityakk9031:fix/rules-centralized-exclusions-extensions

Conversation

@Adityakk9031

Copy link
Copy Markdown
Contributor

, .jsx, .ts, .tsx]).

  • This previously caused rules loaded for Python, Java, Go, C#, Ruby, PHP, and generic search rules to be rejected during file scanning when evaluated by
    ule_applies_to_file.
  • Sets \extensions: None\ so file extension matching remains unrestricted for generic rules.
  • Adds regression unit test in \ ests/unit/exclusion_patterns_tests.rs.

@Adityakk9031

Copy link
Copy Markdown
Contributor Author

@juangaitanv and @Ibrahimrahhal have a look

@juangaitanv
juangaitanv self-requested a review August 17, 2026 08:32

rules.apply_centralized_exclusions(&patterns(), "backend");
let file_types = rules.rules[0].file_types.as_ref().unwrap();
assert!(file_types.extensions.is_none());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

the synthesized fields do not exercise the regressed applicability behavior; could we test rule_applies_to_file for a non-JS path and an excluded path?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants