Update ESLint configuration and dependencies #94
Conversation
- Added TypeScript support in ESLint configuration by including `@typescript-eslint/eslint-plugin` and `@typescript-eslint/parser` at version 8.39.0. - Enhanced ESLint rules with naming conventions for identifiers, interfaces, classes, and constants to improve code quality and consistency. - Updated `package-lock.json` and `package.json` to reflect the new dependencies and their versions. These changes strengthen the linting process for TypeScript files and enforce better coding standards across the project.
WalkthroughScopes the primary ESLint override to TypeScript files, adds a comprehensive @typescript-eslint/naming-convention rule set (multiple selectors, formats, prefixes, and custom regexes) to the main ESLint config, reorders a Prettier import in the ESLint config file, adds @typescript-eslint/parser and @typescript-eslint/eslint-plugin (v8.39.0) to workers/main devDependencies, updates README with development guidelines, and adds an archival document capturing the naming-convention configuration. Test override in the ESLint config is unchanged. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~35 minutes Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
🔍 Vulnerabilities of
|
| digest | sha256:da30eca7154c7c4cb2616e31f7411021ea9146d5b15c68adf2a57df4c52b164c |
| vulnerabilities |     |
| platform | linux/amd64 |
| size | 218 MB |
| packages | 358 |
📦 Base Image alpine:3
| also known as |
|
| digest | sha256:1c4eef651f65e2f7daee7ee785882ac164b02b78fb74503052a26dc061c90474 |
| vulnerabilities |   |
Description
| ||||||||||||
Description
| ||||||||||||
Description | ||||||||||||
Description
| ||||||||||||
Description
| ||||||||||||
Description
| ||||||||||||
Description
| ||||||||||||
Description
| ||||||||||||
Description
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
workers/main/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (2)
workers/main/eslint.config.mjs(2 hunks)workers/main/package.json(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
workers/main/eslint.config.mjs
📄 CodeRabbit Inference Engine (CLAUDE.md)
Linting rules should be defined in workers/main/eslint.config.mjs
Files:
workers/main/eslint.config.mjs
🧠 Learnings (4)
📓 Common learnings
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/tsconfig.json : TypeScript configuration should be defined in workers/main/tsconfig.json
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/eslint.config.mjs : Linting rules should be defined in workers/main/eslint.config.mjs
📚 Learning: 2025-08-05T13:42:48.295Z
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/eslint.config.mjs : Linting rules should be defined in workers/main/eslint.config.mjs
Applied to files:
workers/main/eslint.config.mjs
📚 Learning: 2025-08-05T13:42:48.295Z
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/tsconfig.json : TypeScript configuration should be defined in workers/main/tsconfig.json
Applied to files:
workers/main/eslint.config.mjs
📚 Learning: 2025-08-05T13:42:48.295Z
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to **/*.{ts,tsx} : Use descriptive, unabbreviated variable names; use singular for single values and plural for collections; ensure variable names are context-specific
Applied to files:
workers/main/eslint.config.mjs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Docker Security Scanning (n8n, Dockerfile.n8n, n8n-test:latest)
- GitHub Check: Service Availability Check
- GitHub Check: SonarQube
🔇 Additional comments (1)
workers/main/eslint.config.mjs (1)
4-4: LGTM: Prettier plugin import is correct for flat config.No issues; using
prettier.configs.recommended.rulesplusprettier/prettieris compatible with ESLint 9 flat config.
- Modified ESLint configuration to target only TypeScript files (`**/*.ts`) by removing TypeScript React files (`**/*.tsx`). - Enhanced naming convention rules to exclude const variables from the default identifier rule and updated the filter for variable naming to ensure uppercase constants are not matched. - Added `@typescript-eslint/eslint-plugin` and `@typescript-eslint/parser` as devDependencies in `package.json` to support TypeScript linting. These changes refine the linting process for TypeScript files and improve code quality standards across the project.
- Introduced a new archive file detailing ESLint naming conventions based on the naming-cheatsheet principles to enhance code quality and consistency in the TypeScript codebase. - Updated `eslint.config.mjs` to implement comprehensive naming rules, including camelCase for constants, PascalCase for classes and enums, and specific prefixes for boolean variables and functions. - Enhanced the ESLint configuration to allow flexible naming for object properties, MongoDB operators, and dot notation, ensuring compatibility with various coding patterns. - Updated `package.json` to reflect the latest dependencies and scripts for ESLint. These changes significantly improve the linting process and enforce better coding standards across the project, promoting maintainability and readability.
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (1)
workers/main/eslint.config.mjs (1)
11-15: Enhance TypeScript import resolver configurationNow that we’ve confirmed that
[email protected]is installed in workers/main and your tsconfig.json lives next to the ESLint config, strengthen the resolver to pick up path aliases, type packages, and CommonJS/ESM fallbacks:• File: workers/main/eslint.config.mjs
• Lines: 11–15Apply this diff:
'import/resolver': { - typescript: { - extensions: [".ts"] - }, + typescript: { + project: './tsconfig.json', + alwaysTryTypes: true, + extensions: ['.ts', '.cts', '.mts'] + }, + node: { + extensions: ['.js', '.mjs', '.cjs', '.ts', '.mts', '.cts'] + }, },This ensures ESLint can resolve TS aliases, ambient packages, and fallback to Node’s resolution for JS/TS variants.
🧹 Nitpick comments (8)
workers/main/eslint.config.mjs (4)
40-43: Prefer typescript-eslint flat configs over spreading plugin.configs.*.rules.Using @typescript-eslint/eslint-plugin.configs directly is legacy/classic-config oriented and brittle in flat-config. With v8, import typescript-eslint and use its flat configs (recommendedTypeChecked, stylistic).
Example refactor (high-level):
// import tseslint from 'typescript-eslint'; // export default tseslint.config({ // files: ['**/*.ts'], // languageOptions: { parser: tseslint.parser, parserOptions: { project: './tsconfig.json' } }, // plugins: { '@typescript-eslint': tseslint.plugin }, // rules: { // ...tseslint.configs.recommendedTypeChecked.rules, // ...tseslint.configs.stylisticTypeChecked.rules, // // Your custom rules... // } // })If you keep the current approach, verify that 'recommended-requiring-type-checking' still exists in v8 (it was renamed to recommended-type-checked in the monorepo). Otherwise, switch to the new name to avoid undefined spreads.
42-45: Remove duplicated Prettier enforcement.prettier.configs.recommended already sets 'prettier/prettier': 'error', so the explicit rule duplicates it.
...prettier.configs.recommended.rules, - - 'prettier/prettier': 'error',
31-38: Simplify ignores; avoid redundant patterns.'coverage', 'coverage/', and 'coverage/**/' overlap. Keeping just 'coverage' is sufficient in flat config.
ignores: [ 'node_modules', 'dist', 'eslint.config.mjs', - 'coverage', - 'coverage/*', - 'coverage/**/*' + 'coverage' ],
159-166: Intent check: JS test files won’t inherit the main override’s plugins/rules.The test override correctly relaxes complexity for ['/*.test.ts', '/*.test.js'], but only those two rules will apply to .test.js (no TS plugins, import rules, prettier, etc.). If that’s intentional, fine; otherwise consider a base config object for JS that includes common rules.
memory-bank/archive/archive-eslint-naming-conventions-20250811.md (4)
15-16: Docs vs config: constants casing policy is inconsistent.The archive states “Enforce camelCase for constants,” but the ESLint config’s default rule currently exempts UPPER_CASE via its filter, allowing both camelCase and UPPER_CASE. Decide the intended policy and align code or docs accordingly.
I can generate a doc patch once you confirm the desired behavior.
97-114: Doc lists rules for PascalCase variables (classes/models) and snake_case parameters, but these selectors aren’t present in the ESLint config.If you want these enforced, add the corresponding '@typescript-eslint/naming-convention' entries; otherwise, trim the archive section to reflect the actual configuration.
Happy to generate the exact rule blocks to add into workers/main/eslint.config.mjs.
206-206: Add a language to the fenced code block (markdownlint MD040).One of the code fences lacks a language hint. Append a language like bash, js, or json to the opening ``` to satisfy MD040.
53-71: Prefer requiresQuotes modifier over quoted-string regex in narrative and samples.The archive shows regex allowing quoted properties and dots; in the ESLint ecosystem, modifiers: ['requiresQuotes'] is clearer. Consider updating the doc examples to reflect the recommended pattern.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
memory-bank/archive/archive-eslint-naming-conventions-20250811.md(1 hunks)workers/main/eslint.config.mjs(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
workers/main/eslint.config.mjs
📄 CodeRabbit Inference Engine (CLAUDE.md)
Linting rules should be defined in workers/main/eslint.config.mjs
Files:
workers/main/eslint.config.mjs
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/eslint.config.mjs : Linting rules should be defined in workers/main/eslint.config.mjs
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/tsconfig.json : TypeScript configuration should be defined in workers/main/tsconfig.json
📚 Learning: 2025-08-05T13:42:48.295Z
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/eslint.config.mjs : Linting rules should be defined in workers/main/eslint.config.mjs
Applied to files:
workers/main/eslint.config.mjs
🪛 markdownlint-cli2 (0.17.2)
memory-bank/archive/archive-eslint-naming-conventions-20250811.md
206-206: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Docker Security Scanning (n8n, Dockerfile.n8n, n8n-test:latest)
- GitHub Check: Service Availability Check
🔇 Additional comments (1)
workers/main/eslint.config.mjs (1)
67-80: Confirm intended behavior for UPPER_CASE identifiersI didn’t find any local docs or README entries that explicitly say “constants are camelCase.” The ESLint comment even calls these “SQL constants,” which suggests UPPER_CASE is a deliberate exemption. Please clarify which you prefer:
• If you want all identifiers (including constants) to be camelCase, drop the UPPER_CASE exemption in workers/main/eslint.config.mjs:
filter: { - regex: '^[\'"].*[\'"]$|^[A-Z_]+$', + // Only ignore quoted names; flag UPPER_CASE as well + regex: '^[\'"].*[\'"]$', match: false }• If you want to continue allowing UPPER_CASE for true constants (e.g. SQL constants), keep the current filter but add a section in README.md (or docs/) to explain that exception.
Let me know which path you’d like to take!
- Updated the archive file to include recent enhancements in ESLint naming conventions, specifically enforcing camelCase for boolean variables and functions while maintaining prefix requirements. - Modified `eslint.config.mjs` to implement camelCase formatting for boolean variables and functions, ensuring better code consistency and readability. - Added new rules to allow specific patterns for class/model variables and snake_case for parameters, enhancing flexibility in naming conventions. These changes improve the linting process and enforce stricter naming standards across the TypeScript codebase, promoting maintainability and clarity.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
workers/main/eslint.config.mjs (1)
9-9: Include .tsx files in the TypeScript configuration scopeThe current configuration only targets
.tsfiles. Consider including.tsxfiles for comprehensive TypeScript support:- files: ['**/*.ts'], + files: ['**/*.ts', '**/*.tsx'],This ensures that TypeScript React components also benefit from the naming conventions and other rules.
🧹 Nitpick comments (1)
workers/main/eslint.config.mjs (1)
126-133: Consider a more maintainable approach for class/model variable exceptionsThe hardcoded list of specific variable names is not scalable and requires manual updates for each new repository or model class. Consider using a pattern-based approach:
- { - selector: 'variable', - format: null, - custom: { - regex: '^(FinAppRepository|TargetUnitRepository|TestModel|EmployeeModel|ProjectModel|SlackServiceNoToken|SlackServiceNoChannel)$', - match: true - } - }, + { + selector: 'variable', + format: ['PascalCase'], + filter: { + // Match variables ending with common suffixes for classes + regex: '(Repository|Model|Service|Controller|Factory|Manager)$', + match: true + } + },This approach automatically handles new repositories, models, and services without requiring config updates.
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
memory-bank/archive/archive-eslint-naming-conventions-20250811.mdis excluded by!memory-bank/**
📒 Files selected for processing (1)
workers/main/eslint.config.mjs(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
workers/main/eslint.config.mjs
📄 CodeRabbit Inference Engine (CLAUDE.md)
Linting rules should be defined in workers/main/eslint.config.mjs
Files:
workers/main/eslint.config.mjs
🧠 Learnings (3)
📓 Common learnings
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/eslint.config.mjs : Linting rules should be defined in workers/main/eslint.config.mjs
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/tsconfig.json : TypeScript configuration should be defined in workers/main/tsconfig.json
📚 Learning: 2025-08-05T13:42:48.295Z
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/eslint.config.mjs : Linting rules should be defined in workers/main/eslint.config.mjs
Applied to files:
workers/main/eslint.config.mjs
📚 Learning: 2025-08-05T13:42:48.295Z
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to **/*.{ts,tsx} : Follow the function naming pattern: prefix? + action (A) + high context (HC) + low context? (LC), using action verbs such as get, fetch, send, create, validate, handle, calculate, and boolean prefixes is, has, should
Applied to files:
workers/main/eslint.config.mjs
- Revised the archive file to reflect recent updates in ESLint naming conventions, including the transition to PascalCase for boolean variables and functions, and the addition of new function prefixes such as 'setup', 'create', 'init', and 'build'. - Enhanced `eslint.config.mjs` to implement these changes, ensuring better support for naming patterns and improved variable filtering. - Introduced a new rule for true constants to use UPPER_CASE formatting, further refining the naming standards. These updates enhance code quality and consistency across the TypeScript codebase, promoting maintainability and clarity.
|
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
workers/main/eslint.config.mjs (1)
66-169: Add missing rule for const primitive variables.The naming convention rules are missing enforcement for primitive const variables to use UPPER_CASE (e.g.,
const MAX_RETRIES = 5).Add this rule after line 133:
}, + // True constants (primitive literals) should be UPPER_CASE + { + selector: 'variable', + modifiers: ['const'], + types: ['string', 'number', 'boolean'], + format: ['UPPER_CASE'] + }, // Parameters that can be snake_case (for API/DB compatibility)
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
memory-bank/archive/archive-eslint-naming-conventions-20250811.mdis excluded by!memory-bank/**
📒 Files selected for processing (1)
workers/main/eslint.config.mjs(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
workers/main/eslint.config.mjs
📄 CodeRabbit Inference Engine (CLAUDE.md)
Linting rules should be defined in workers/main/eslint.config.mjs
Files:
workers/main/eslint.config.mjs
🧠 Learnings (3)
📓 Common learnings
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/eslint.config.mjs : Linting rules should be defined in workers/main/eslint.config.mjs
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/tsconfig.json : TypeScript configuration should be defined in workers/main/tsconfig.json
📚 Learning: 2025-08-05T13:42:48.295Z
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/eslint.config.mjs : Linting rules should be defined in workers/main/eslint.config.mjs
Applied to files:
workers/main/eslint.config.mjs
📚 Learning: 2025-08-05T13:42:48.295Z
Learnt from: CR
PR: speedandfunction/automatization#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to **/*.{ts,tsx} : Follow the function naming pattern: prefix? + action (A) + high context (HC) + low context? (LC), using action verbs such as get, fetch, send, create, validate, handle, calculate, and boolean prefixes is, has, should
Applied to files:
workers/main/eslint.config.mjs
🔇 Additional comments (2)
workers/main/eslint.config.mjs (2)
4-4: LGTM! Import reordering is a good practice.The reordering of the prettier import improves consistency and follows standard import sorting conventions.
9-9: ESLint scope is sufficient for current file typesI checked under workers/main and found only
.ts/.test.tsfiles—no.tsxor.test.jsfiles exist. The base patternfiles: ['**/*.ts']plus the npm scripteslint . --ext .tswill lint all existing source and test files. No extension gaps to address at this time.
@typescript-eslint/eslint-pluginand@typescript-eslint/parserat version 8.39.0.package-lock.jsonandpackage.jsonto reflect the new dependencies and their versions.These changes strengthen the linting process for TypeScript files and enforce better coding standards across the project.
Summary by CodeRabbit