Expand ESLint exceptions for identifier length and unused variable rules

[TheCodeDestroyer]

Summary by CodeRabbit

• New Features
  • Updated linting rules to allow unused variables starting with an underscore (_) without triggering errors.
  • Expanded exceptions for identifier length, permitting single-character variable names such as 'x', 'y', 'z', and 'q'.
• Tests
  • Added tests to verify that unused variables prefixed with an underscore are ignored by linting rules.
  • Added tests to confirm allowed single-character identifiers do not trigger linting errors.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5ced415

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@tcd-devkit/eslint-config	Minor
@tcd-devkit/eslint-config-ts	Minor
@tcd-devkit/eslint-preset-next	Patch
@tcd-devkit/eslint-preset-node	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

📝 Walkthrough

Walkthrough

This update modifies ESLint configurations for TypeScript and JavaScript projects by expanding exceptions for identifier length and unused variable rules. It introduces new ignore patterns for unused variables prefixed with underscores, adds more allowed single-character identifiers, and includes corresponding test coverage for the new TypeScript rule.

Changes

Files/Paths	Change Summary
.changeset/modern-grapes-sit.md .changeset/tidy-zoos-taste.md	Added changeset files documenting updates to ESLint config packages.
packages/eslint/eslint-config/src/base.rules.ts packages/eslint/eslint-config/src/tests/rules/id-length.test.ts	Expanded id-length rule exceptions to include 'x', 'y', 'z', and 'q'; updated and added tests for these exceptions.
packages/eslint/eslint-config-ts/src/ts.rules.ts packages/eslint/eslint-config-ts/src/tests/rules/no-unused-vars.test.ts	Added @typescript-eslint/no-unused-vars rule with ignore pattern for variables starting with '_'; added tests verifying this behavior.

Sequence Diagram(s)

sequenceDiagram
    participant Developer
    participant ESLint Config
    participant Linter
    participant Test Suite

    Developer->>ESLint Config: Adds/updates rules (id-length, no-unused-vars)
    Linter->>ESLint Config: Loads updated rules
    Linter->>Codebase: Runs lint checks
    Linter->>Test Suite: Executes test cases for no-unused-vars
    Test Suite->>Linter: Receives lint results
    Test Suite->>Developer: Reports test outcomes

Loading

Possibly related PRs

• Allow exceptions for 'i', 'e', and '_' in ESLint id-length rule #38: Expands the exceptions list for the ESLint id-length rule, directly related to the current update that adds more allowed identifiers.

Poem

In the land of lint, where the rules are tight,
New names join the list, now x, y, and z are right.
Unused vars with underscores slip by unseen,
While tests hop along, keeping the codebase clean.
🐇✨

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

Scope: all 4 workspace projects
Progress: resolved 0, reused 0, downloaded 1, added 0
/tmp/eslint/packages/eslint-presets/eslint-preset-node:
 ERR_PNPM_WORKSPACE_PKG_NOT_FOUND  In packages/eslint-presets/eslint-preset-node: "@tcd-devkit/eslint-config@workspace:*" is in the dependencies but no package named "@tcd-devkit/eslint-config" is present in the workspace

This error happened while installing a direct dependency of /tmp/eslint/packages/eslint-presets/eslint-preset-node

Packages found in the workspace:

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fc99c60 and 5ced415.

📒 Files selected for processing (6)

• .changeset/modern-grapes-sit.md (1 hunks)
• .changeset/tidy-zoos-taste.md (1 hunks)
• packages/eslint/eslint-config-ts/src/__tests__/rules/no-unused-vars.test.ts (1 hunks)
• packages/eslint/eslint-config-ts/src/ts.rules.ts (1 hunks)
• packages/eslint/eslint-config/src/__tests__/rules/id-length.test.ts (2 hunks)
• packages/eslint/eslint-config/src/base.rules.ts (1 hunks)

✅ Files skipped from review due to trivial changes (1)

• packages/eslint/eslint-config-ts/src/tests/rules/no-unused-vars.test.ts

🚧 Files skipped from review as they are similar to previous changes (4)

• .changeset/modern-grapes-sit.md
• .changeset/tidy-zoos-taste.md
• packages/eslint/eslint-config-ts/src/ts.rules.ts
• packages/eslint/eslint-config/src/base.rules.ts

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/eslint/eslint-config-import/src/__tests__/rules/no-deprecated.test.ts:17-28
Timestamp: 2025-05-23T19:24:06.831Z
Learning: The `import-x/no-deprecated` ESLint rule can generate multiple lint messages for a single deprecated import statement. A single deprecated import can result in 2 errors due to the rule's internal behavior, not because there are multiple deprecated imports in the code.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/eslint/eslint-config-import/src/__tests__/rules/no-deprecated.test.ts:17-28
Timestamp: 2025-05-23T19:24:06.831Z
Learning: The `import-x/no-deprecated` ESLint rule generates separate lint messages for both importing deprecated exports and using those deprecated exports. A single deprecated import scenario can result in 2 lint messages: one for the import statement and another for the usage/call of the deprecated function.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/eslint/eslint-config-react/src/react.linter.ts:20-20
Timestamp: 2025-05-23T17:50:17.181Z
Learning: ESLint configuration packages in the @tcd-devkit ecosystem are designed to be consumed by external projects, so they may include file patterns and extensions (like mjsx, mtsx) that aren't used in the current monorepo but might be needed by consuming projects.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/internal-utils/package.json:55-55
Timestamp: 2025-05-23T19:27:10.314Z
Learning: Each individual ESLint config package in the @tcd-devkit monorepo has its own "imports" field that maps "#*" to their source files, enabling alias imports like #react.linter within their own package scope. The internal-utils package doesn't need an "imports" field when it only contains one source file.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/tsconfig/tsconfig.next.json:8-9
Timestamp: 2025-05-23T17:46:43.106Z
Learning: The `${configDir}` template variable in TypeScript configuration files is a legitimate TypeScript 5.5 feature that gets automatically resolved by the TypeScript compiler. It should not be flagged as problematic since TypeScript natively supports this template variable interpolation in configuration files.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/eslint/eslint-config-next/package.json:68-68
Timestamp: 2025-05-23T19:29:58.142Z
Learning: In packages/eslint/eslint-config-next/package.json, the dependency "@next/eslint-plugin-next": "15.4.0-canary.45" is intentionally using a canary version for enhanced types support that isn't available in stable versions yet. The maintainer plans to switch to stable once these features are officially released.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/eslint/eslint-config-a11y/src/typings/eslint-plugin-jsx-a11y.d.ts:1-14
Timestamp: 2025-05-23T19:25:15.891Z
Learning: In TypeScript module declaration files (.d.ts) using `declare module`, adding explicit import statements for types can cause TypeScript compilation crashes and prevent module declarations from being detected. Types like Linter.Config and Linter.LegacyConfig from ESLint are typically available as ambient types without explicit imports in this context.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/eslint/eslint-config-ts/src/ts.linter.ts:19-19
Timestamp: 2025-05-23T19:30:46.588Z
Learning: In the @tcd-devkit codebase, TypeScript ESLint configurations use double type assertion `as unknown as Linter.Config[]` to convert from typescript-eslint's ConfigArray type to standard ESLint Linter.Config[] type for maintaining type consistency across all ESLint configurations.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#32
File: eslint.config.mjs:5-10
Timestamp: 2025-05-31T20:36:11.700Z
Learning: The NextJS ESLint plugin (@next/eslint-plugin-next) exports a default named plugin that requires importing as a default export and then destructuring the needed configuration (e.g., flatConfig). This pattern triggers the `import-x/no-rename-default` rule, necessitating a global disable of this rule when using NextJS ESLint configurations.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/tsconfig/tsconfig.next.json:8-9
Timestamp: 2025-05-23T17:46:43.106Z
Learning: The `${configDir}` template variable in TypeScript configuration files is a legitimate TypeScript 5.5 feature (released June 2024) that gets automatically resolved by the TypeScript compiler to the containing directory of the configuration file. It can be used in path-related fields like `include`, `exclude`, `outDir`, `rootDir`, `paths`, and `typeRoots`. This feature was specifically designed to solve path resolution issues in shared configurations and monorepos.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/internal-utils/src/test.utils.ts:0-0
Timestamp: 2025-05-23T18:45:38.179Z
Learning: TheCodeDestroyer prefers consistent API design and likes to use unified interface names when functions share similar option patterns, even if some properties aren't used by all functions.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/eslint/eslint-config-import-ts/package.json:65-67
Timestamp: 2025-05-23T19:34:31.271Z
Learning: TheCodeDestroyer prefers to use Renovate for automated dependency management rather than manual dependency version updates in package.json files.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#7
File: renovate.json:2-4
Timestamp: 2025-05-25T09:20:16.838Z
Learning: TheCodeDestroyer prefers using local Renovate presets with the "local>" syntax to avoid external fetches, rather than GitHub-based presets.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: package.json:13-16
Timestamp: 2025-05-23T18:52:37.598Z
Learning: TheCodeDestroyer uses Turbo for all development task orchestration in the monorepo, with proper commands defined in turbo.json rather than npm scripts. They prefer `turbo run` commands over direct npm script execution for development workflows.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#7
File: renovate.json:2-4
Timestamp: 2025-05-25T09:20:16.838Z
Learning: TheCodeDestroyer uses local Renovate presets correctly with syntax "local>thecodedestroyer/devkit//packages/renovate" which resolves to "packages/renovate/default.json". Local presets avoid external fetches and are preferred for self-contained monorepo configurations.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#7
File: renovate.json:2-4
Timestamp: 2025-05-25T09:20:16.838Z
Learning: TheCodeDestroyer prefers using local Renovate presets with the "local>" syntax to avoid external fetches. The syntax "local>thecodedestroyer/devkit//packages/renovate" is correct for referencing local presets within the same repository.

packages/eslint/eslint-config/src/__tests__/rules/id-length.test.ts (2)

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/eslint/eslint-config-import/src/__tests__/rules/no-deprecated.test.ts:17-28
Timestamp: 2025-05-23T19:24:06.831Z
Learning: The `import-x/no-deprecated` ESLint rule can generate multiple lint messages for a single deprecated import statement. A single deprecated import can result in 2 errors due to the rule's internal behavior, not because there are multiple deprecated imports in the code.

Learnt from: TheCodeDestroyer
PR: TheCodeDestroyer/devkit#5
File: packages/eslint/eslint-config-import/src/__tests__/rules/no-deprecated.test.ts:17-28
Timestamp: 2025-05-23T19:24:06.831Z
Learning: The `import-x/no-deprecated` ESLint rule generates separate lint messages for both importing deprecated exports and using those deprecated exports. A single deprecated import scenario can result in 2 lint messages: one for the import statement and another for the usage/call of the deprecated function.

🧬 Code Graph Analysis (1)

packages/eslint/eslint-config/src/__tests__/rules/id-length.test.ts (1)

packages/eslint/eslint-config/src/base.linter.ts (1)

• baseConfig (22-30)

⏰ Context from checks skipped due to timeout of 90000ms (1)

• GitHub Check: main

🔇 Additional comments (2)

packages/eslint/eslint-config/src/__tests__/rules/id-length.test.ts (2)

13-14: Good update to maintain test integrity.

The change from x and y to a and b is necessary since x and y are now on the exceptions list. This ensures the failing test continues to properly validate that non-excepted short identifiers trigger the rule.

---

30-44: Excellent test coverage for the expanded exceptions list.

The new test case comprehensively validates that all identifiers on the expanded exceptions list (i, e, _, x, y, z, q) are properly allowed by the id-length rule. The test structure follows the existing pattern and provides good coverage for the new functionality.

✨ Finishing Touches

• 📝 Generate Docstrings

🧪 Generate Unit Tests

• Create PR with Unit Tests
• Post Copyable Unit Tests in Comment
• Commit Unit Tests in branch add-more-allowed-ids

---

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Explain this complex logic.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai explain this code block.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and explain its main purpose.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai auto-generate unit tests to generate unit tests for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.