feat(linter): inherit rules via the extended config files#9308
Merged
graphite-app[bot] merged 1 commit intomainfrom Mar 4, 2025
Merged
Conversation
This was referenced Feb 23, 2025
Member
Author
github-actions
bot
added
A-linter
camchenry
force-pushed
the
02-23-feat_linter_inherit_rules_via_the_extended_config_files
branch
from
971831f to
789e166
Compare
camchenry
force-pushed
the
02-18-feat_linter_add_support_for_extends_property_in_oxlintrc
branch
from
7f3a3de to
c92ba6c
Compare
camchenry
force-pushed
the
02-23-feat_linter_inherit_rules_via_the_extended_config_files
branch
from
789e166 to
fd06c26
Compare
CodSpeed Performance ReportMerging #9308 will create unknown performance changesComparing Summary
Benchmarks breakdown
|
camchenry
force-pushed
the
02-23-feat_linter_inherit_rules_via_the_extended_config_files
branch
2 times, most recently
from
3e96436 to
dd36f3c
Compare
camchenry
force-pushed
the
02-18-feat_linter_add_support_for_extends_property_in_oxlintrc
branch
from
c92ba6c to
dfdbb48
Compare
camchenry
force-pushed
the
02-23-feat_linter_inherit_rules_via_the_extended_config_files
branch
from
dd36f3c to
4cfdc59
Compare
This was referenced Mar 1, 2025
Sysix
approved these changes
Mar 2, 2025
camchenry
force-pushed
the
02-18-feat_linter_add_support_for_extends_property_in_oxlintrc
branch
from
dfdbb48 to
7cab29f
Compare
camchenry
force-pushed
the
02-23-feat_linter_inherit_rules_via_the_extended_config_files
branch
from
4cfdc59 to
63b413f
Compare
Member
Author
Merge activity
|
- part of #9307 This gives the `extends` keyword some functionality: specifically to allow inheriting rules from other configuration files. Rules that are in the extended configuration will be used as the base, and then files in the config doing the extending will override the extended rules. So, you can, for example, specify a base configuration that defines rules that you generally want to be enabled. Then, in each nested configuration file, you could disable rules depending on the directory: ```text .oxlintrc.json // { "rules: { "no-useless-escape": "error" } } package1/ .oxlintrc.json // { "extends": ["../.oxlintrc.json"], "rules": { "no-useless-escape": "off" } } package2/ src // uses ../.oxlintrc.json with `no-useless-escape` enabled ``` As a side effect of this, building a config from a `.oxlintrc.json` file can result in config errors, even if all of the syntax and rules are configured correctly, because an extended configuration file might be incorrect or unparseable. For now, we simply raise an error if this occurs and stop execution, but in the future we could make this more graceful if we wanted and just ignore that file. We will also need to revisit performance here, as I think a global cache config might be necessary so that we never load a file more than once and parse it more than once.
graphite-app
bot
force-pushed
the
02-18-feat_linter_add_support_for_extends_property_in_oxlintrc
branch
from
7cab29f to
3fce826
Compare
graphite-app
bot
force-pushed
the
02-23-feat_linter_inherit_rules_via_the_extended_config_files
branch
from
63b413f to
fc74849
Compare
Base automatically changed from
02-18-feat_linter_add_support_for_extends_property_in_oxlintrc
to
main
March 4, 2025 02:41
graphite-app
bot
deleted the
02-23-feat_linter_inherit_rules_via_the_extended_config_files
branch
Boshen
added a commit
that referenced
this pull request
Mar 11, 2025
## [0.15.14] - 2025-03-11 ### Features - 0815fe8 linter: Add `promise/no-return-wrap` (#9537) (therewillbecode) - ae7bb75 linter: Add react/jsx-filename-extension rule (#9474) (Cédric DIRAND) - 50327f3 linter: Add import/exports-last (#9578) (yefan) - 75e4b8d linter: Add import/no-anonymous-default-export rule (#9481) (yefan) - 2f08b16 linter: Add `promise/prefer-catch` (#9488) (therewillbecode) - 41f32ea linter: Allow adding more overrides via `extends` configs (#9475) (camchenry) - fb7cf10 linter: Allowing `plugins` to be extended with `extends` (#9473) (camchenry) - fc74849 linter: Inherit `rules` via the extended config files (#9308) (camchenry) - 3fce826 linter: Add support for `extends` property in oxlintrc (#9217) (camchenry) ### Bug Fixes - 2d42569 linter: Rule `eslint/no-unsafe-optional-chaining` (#9632) (therewillbecode) - a9d7df9 linter: False positive in `unicorn/escape-case` (#9638) (shulaoda) - 3831819 linter: Fix example lint declaration and macro syntax (#9626) (Uli) - 4ca62ab linter: Output right file line and column for `.vue`, `.astro` and `.svelte` files (#9484) (Sysix) - 3105159 linter: Do not output number of rules with nested configs (#9476) (camchenry) - 5ecda01 linter: Support nested extending (#9472) (camchenry) ### Documentation - b7c61e9 linter: Improve docs for `eslint-guard-for-in` (#9658) (therewillbecode) - 1cc43f7 linter: Improve the documentation of `eslint-no-console` (#9612) (therewillbecode) - 608bb77 linter: Improve the docs and add test case for `typescript-no-extra-non-null-assertion` (#9609) (therewillbecode) - 43add5d linter: Better docs for `typescript-no-non-null-asserted-nullish-coalescing` rule (#9610) (therewillbecode) - bd90ce6 linter: Improve the docs and add test cases for `eslint-no-shadow-restricted-names` (#9597) (therewillbecode) - a0c9f7c linter: Improve the documentation of `eslint-no-func-assign` (#9596) (therewillbecode) - ec922e9 linter: Improve the documentation of `typescript-consistent-type-definitions` (#9575) (therewillbecode) - 165c89d linter: Improve the documentation of `typescript-no-namespace` (#9545) (therewillbecode) ### Refactor - c174600 linter: Improve `eslint/no-duplicate-imports` (#9627) (therewillbecode) - 31ba425 linter: Improve `eslint/no-self-assign` (#9635) (therewillbecode) - 03a40df linter: Access scoping from `ctx` directly (#9624) (Boshen) - be5e5dc linter: Improve `unicorn/escape-case` (#9568) (shulaoda) - b7f82fc linter: Improve `unicorn/error-message` (#9560) (shulaoda) - 069ef2d linter: Improve `promise/no-nesting` (#9544) (therewillbecode) - 62bffed rust: Allow a few annoying clippy rules (#9588) (Boshen) ### Testing - 934a387 linter: Remove test dependency on oxlint (#9513) (camchenry) Co-authored-by: Boshen <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
extendskeyword #9307This gives the
extendskeyword some functionality: specifically to allow inheriting rules from other configuration files. Rules that are in the extended configuration will be used as the base, and then files in the config doing the extending will override the extended rules.So, you can, for example, specify a base configuration that defines rules that you generally want to be enabled. Then, in each nested configuration file, you could disable rules depending on the directory:
As a side effect of this, building a config from a
.oxlintrc.jsonfile can result in config errors, even if all of the syntax and rules are configured correctly, because an extended configuration file might be incorrect or unparseable. For now, we simply raise an error if this occurs and stop execution, but in the future we could make this more graceful if we wanted and just ignore that file.We will also need to revisit performance here, as I think a global cache config might be necessary so that we never load a file more than once and parse it more than once.