eslint-config

Clear and concise description of the problem As a developer using this project I want ESLint to also respect so that personal-only ignores (, personal AI scratch files, debug logs, etc.) don't need to be added to the team to silence the linter. Git itself treats as a first-class ignore layer right next to , but (the default) only reads the latter. So if I add and some docs to to avoid polluting the team , ESLint still happily lints my and fails. Suggested solution In , when is true, pass alongside to . Alternative _No response_ Additional context This is intentionally different from the previously declined request in . That one required running for every ESLint invocation; is a fixed path inside the repo with zero extra lookup cost, and the upstream parser already handles its gitignore syntax. Validations [x] Follow our Code of Conduct [x] Read the Contributing Guide. [x] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Summary Would you be open to removing from the default dependency graph, while preserving the small subset of Unicorn rules currently enabled by through existing plugins, ESLint core rules, and a few focused rules in ? This is not a proposal to remove Unicorn integration entirely. Users who want or arbitrary Unicorn overrides could still opt in explicitly through an optional peer dependency. Motivation currently: enables Unicorn by default in ; uses only 15 Unicorn rules in its default preset in ; installs the entire plugin as a hard dependency and imports it statically through . Disabling it with therefore avoids running the rules, but does not remove Unicorn or its transitive dependencies from installation. This became more visible in . Compared with , its unpacked production dependency tree increased by approximately 3.6 MB: Using the currently resolved production dependency trees and npm registry metadata: : approximately 7.047 MB across 38 packages : approximately 10.623 MB across 43 packages The exact installed delta varies with package-manager deduplication, but none of the three rules responsible for the new large dependencies are enabled by the default Antfu preset. This is also not a one-off case. For example, Unicorn's imports , , and . Their current combined production subtree is roughly 2.87 MB, primarily from and . is useful for that rule, but the rule is not among the 15 enabled by . In other words, every user pays the dependency cost of the entire plugin, including dependencies used only by rules that the default config never enables, even though the preset enables only 15 Unicorn rules. Audit of the 15 enabled rules I looked for replacements in ESLint core and plugins that are already dependencies of this preset. This suggests that we do not need to reproduce all of Unicorn: 1. Reuse for and . 2. Reuse type-aware rules where available. 3. Reuse for the regex portion of . 4. Let existing core rules handle the behavior they already cover. 5. Add only the remaining small, high-value gaps to , after deciding which preferences are worth preserving. Parity tests could run the previous Unicorn rules and the replacements against the same fixtures, making intentional coverage differences visible. About I also evaluated as a lightweight alternative. It is small and currently has no runtime dependencies, but its rules are not drop-in replacements for the enabled Unicorn rules: is broader and semantically different from : it discourages generic generally and suggests custom error classes, while Unicorn changes to only in recognized type-checking branches. overlaps the ESLint core rule already enabled by this preset. It currently has no equivalents for , , or . All three fit the plugin's error-handling scope well, so proposing or contributing them there may be preferable to creating Antfu-specific versions immediately. Therefore, adding it today would not recover the desired behavior. A reasonable first option is to propose or contribute the three error-focused rules, namely , , and , upstream, then use only for rules that are too specific to this preset or cannot find a suitable shared home. Proposed migration Because currently defaults to and supports , this would likely belong in a major release. A possible migration path: 1. Add or select replacements for the current default 15-rule subset. 2. Move the remaining accepted rules or partial-rule gaps into . 3. Remove the static Unicorn import and hard dependency. 4. Keep full Unicorn support as explicit opt-in through an optional peer dependency loaded only when is explicitly requested. 5. Document any intentional reductions in JavaScript versus type-aware TypeScript coverage. Users who want the full Unicorn preset would continue to install themselves. Users of the default preset would no longer pay for dependencies needed only by rules that the preset never enables. Would this direction be acceptable? In particular: 1. Is preserving exact behavior for all 15 rules required, or can low-value/mostly stylistic rules be dropped? 2. Would be the preferred home for the remaining focused rules? 3. Should full Unicorn support remain available as an optional peer integration? This issue was created with assistance from a code agent.*

Is there a reason why and are missing in the options? For integrating TailwindCSS with Vuetify, it is important to have the style imports before others like . Is there a different strategy to deal with this? https://github.com/antfu/eslint-config/blob/5ada54fd1f6527b012203c9694212eb8fa11bc82/src/configs/perfectionist.ts#L25