test: Enable test full tests for rules #389
Draft
Conversation
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
## Summary - Uncommented the test file for the `ban-ts-comment` rule in `rstest.config.mts` to enable testing of the TypeScript-ESLint ban-ts-comment rule implementation ## Context This PR enables the test for the `ban-ts-comment` rule as requested. The test file was previously commented out in the test configuration. ## Changes - Uncommented line 35 in `/home/runner/work/rslint/rslint/packages/rslint-test-tools/rstest.config.mts` - This enables the test suite at `./tests/typescript-eslint/rules/ban-ts-comment.test.ts` ## Test Plan - [ ] Run `npm test` to verify all tests pass - [ ] Check CI pipeline for any failures - [ ] Fix any implementation issues if tests fail ## Implementation Notes The Go implementation is located at `/home/runner/work/rslint/rslint/internal/plugins/typescript/rules/ban_ts_comment/ban_ts_comment.go`. If tests fail in CI, the implementation may need adjustments to match the TypeScript-ESLint reference behavior at https://typescript-eslint.io/rules/ban-ts-comment/. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Donny/강동윤 <kdy.1997.dev@gmail.com>
## Summary - Uncommented the test file for the `ban-tslint-comment` rule in `rstest.config.mts` to enable testing - Implemented the ban-tslint-comment rule in Go - Registered the rule in the configuration ## Context This PR is a follow-up to #149 which enabled the `ban-ts-comment` rule. This PR enables the `ban-tslint-comment` rule which helps enforce migration from deprecated TSLint to ESLint. ## Changes 1. **Test Configuration** (rstest.config.mts:36) - Uncommented the line enabling the ban-tslint-comment test file 2. **Implementation** (internal/plugins/typescript/rules/ban_tslint_comment/ban_tslint_comment.go) - Created new Go implementation for the ban-tslint-comment rule - Detects `tslint:disable` and `tslint:enable` comments in both single-line (`//`) and multi-line (`/* */`) formats - Provides automatic fixes that remove tslint comments - Handles various comment positions (standalone lines and inline comments) - Reports errors with messageId 'commentDetected' and appropriate description 3. **Registration** (internal/config/config.go) - Added import for the ban_tslint_comment package - Registered the rule as `@typescript-eslint/ban-tslint-comment` ## Implementation Details The rule implementation: - Scans source text for tslint comment patterns - Matches comments starting with `tslint:disable` or `tslint:enable` - Creates fixes that intelligently remove comments: - For standalone comment lines: removes the entire line including newline - For inline comments (e.g., `someCode(); // tslint:disable-line`): removes just the comment - Follows the pattern established by the ban-ts-comment rule ## Test Plan - [x] Run `npm test` to verify all tests pass - [ ] Check CI pipeline for any failures - [ ] Fix any implementation issues if tests fail in CI ## TypeScript-ESLint Reference The implementation follows the behavior of the TypeScript-ESLint ban-tslint-comment rule: https://typescript-eslint.io/rules/ban-tslint-comment/ TSLint was deprecated in favor of ESLint, and this rule helps enforce the migration by detecting and removing TSLint directive comments. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
## Summary - Uncommented the test file for the `class-methods-use-this` rule in `rstest.config.mts` to enable testing - Implemented the class-methods-use-this rule in Go - Registered the rule in the configuration ## Context This PR is a follow-up to #151 which enabled the `ban-tslint-comment` rule. This PR enables the `class-methods-use-this` rule which detects class methods that don't use `this` and could be made static. ## Changes 1. **Test Configuration** (rstest.config.mts:37) - Uncommented the line enabling the class-methods-use-this-core test file 2. **Implementation** (internal/plugins/typescript/rules/class_methods_use_this/class_methods_use_this.go) - Created new Go implementation for the class-methods-use-this rule - Detects class methods, getters, setters, and class fields that don't use `this` or `super` - Supports options: - `exceptMethods`: array of method names to ignore - `enforceForClassFields`: boolean to control checking of class fields (default: true) - Properly handles: - Instance methods, getters, setters - Private methods (with # prefix) - Generator methods - Arrow functions and function expressions in class fields - Nested functions and arrow functions (correctly scoping `this`) - Skips constructors, static methods, and abstract methods 3. **Registration** (internal/config/config.go) - Added import for the class_methods_use_this package - Registered the rule as `@typescript-eslint/class-methods-use-this` ## Implementation Details The rule implementation: - Traverses class members (methods, getters, setters, properties) - Checks if each member's body uses `this` or `super` keywords - Handles nested function scoping correctly (doesn't look inside nested function expressions, but does check arrow functions as they capture `this`) - Respects exception list for method names - Reports errors with messageId 'missingThis' and appropriate description ## Test Plan - [ ] Run `npm test` to verify all tests pass - [ ] Check CI pipeline for any failures - [ ] Fix any implementation issues if tests fail in CI ## TypeScript-ESLint Reference The implementation follows the behavior of the TypeScript-ESLint class-methods-use-this rule: https://typescript-eslint.io/rules/class-methods-use-this/ 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
## Summary - Uncommented the full test file for class-methods-use-this rule in `rstest.config.mts` - Extended implementation to support `ignoreClassesThatImplementAnInterface` option (boolean or "public-fields") - Extended implementation to support `ignoreOverrideMethods` option - All tests now pass successfully ## Context This PR is a follow-up to #152 and #153, which enabled the core test. This PR enables the full test suite with advanced TypeScript-specific features. ## Changes ### Test Configuration (rstest.config.mts:38) - Uncommented the line enabling the class-methods-use-this full test file ### Implementation (internal/plugins/typescript/rules/class_methods_use_this/class_methods_use_this.go) Extended the rule to support advanced TypeScript-ESLint options: 1. **ignoreClassesThatImplementAnInterface**: - When `true`: ignores all members of classes that implement interfaces - When `"public-fields"`: only ignores public members, still checks private/protected members - When `false`: checks all members (default behavior) 2. **ignoreOverrideMethods**: - When `true`: ignores methods with the `override` modifier - When `false`: checks override methods (default behavior) 3. **Implementation details**: - Added helper functions to check if a class implements an interface - Added helper to check if a member has the override modifier - Added logic to determine whether to ignore members based on: - Class interface implementation status - Member visibility (public/private/protected) - Override modifier presence - Applied these checks to both methods and property initializers ### Test Snapshots - Created snapshot file with 40 test cases covering: - Basic method detection - Private/protected methods - Getter/setter detection - Classes implementing interfaces - Override methods - Property initializers - Combination of options ## Test Results All tests pass successfully: - Valid test cases: ✓ (3.53s) - Invalid test cases: ✓ (4.06s) - Total: 2 passed ## TypeScript-ESLint Reference The implementation follows the behavior of the TypeScript-ESLint class-methods-use-this rule: https://typescript-eslint.io/rules/class-methods-use-this/ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
## Summary - Uncommented the test file for consistent-generic-constructors rule in `rstest.config.mts` - All tests now pass successfully ## Context This PR is a follow-up to #154, which enabled the test for class-methods-use-this rule. This PR enables the test suite for consistent-generic-constructors. ## Changes ### Test Configuration (rstest.config.mts:39) - Uncommented the line enabling the consistent-generic-constructors test file ### Implementation Status The Go implementation at `internal/plugins/typescript/rules/consistent_generic_constructors/` already supports all required features: 1. **Default 'constructor' style**: Enforces type arguments on constructor calls - Example: `const a = new Foo<string>();` 2. **'type-annotation' style option**: Enforces type arguments on type annotations - Example: `const a: Foo<string> = new Foo();` 3. **Comprehensive coverage**: - Variable declarations - Property declarations (including accessor properties) - Function/method parameters - Destructuring patterns - Default parameter values ## Test Results All tests pass successfully: - 50 valid test cases: ✓ - 25 invalid test cases: ✓ - Total: 75 test cases passed ## TypeScript-ESLint Reference The implementation follows the behavior of the TypeScript-ESLint consistent-generic-constructors rule: https://typescript-eslint.io/rules/consistent-generic-constructors/ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
## Summary - Uncommented the test file for consistent-indexed-object-style rule in `rstest.config.mts` - Follow-up to #155, which enabled the test for consistent-generic-constructors rule ## Context This PR enables the test suite for consistent-indexed-object-style rule, which enforces consistent usage of indexed object types in TypeScript. ## Changes ### Test Configuration (rstest.config.mts:40) - Uncommented the line enabling the consistent-indexed-object-style test file ### Implementation Status The Go implementation at `internal/plugins/typescript/rules/consistent_indexed_object_style/` already supports all required features: 1. **Default 'record' style**: Enforces use of `Record<K, V>` utility type - Example: `type Foo = Record<string, any>;` 2. **'index-signature' style option**: Enforces use of index signatures - Example: `type Foo = { [key: string]: any };` 3. **'mapped-type' style option**: Enforces use of mapped types - Example: `type Foo = { [K in string]: any };` 4. **Comprehensive coverage**: - Interface declarations with index signatures - Type literals with index signatures - Mapped types - Record type references - Circular reference detection to avoid false positives ## TypeScript-ESLint Reference The implementation follows the behavior of the TypeScript-ESLint consistent-indexed-object-style rule: https://typescript-eslint.io/rules/consistent-indexed-object-style/ ## Documentation References - TypeScript index signatures: https://www.typescriptlang.org/docs/handbook/2/objects.html#index-signatures - Record utility type: https://www.typescriptlang.org/docs/handbook/utility-types.html#recordkeys-type 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
## Summary - Uncommented the `consistent-type-exports.test.ts` test file in the rstest configuration (line 44 of `packages/rslint-test-tools/rstest.config.mts`) - This enables testing for the `consistent-type-exports` rule, which enforces the use of type-only exports when exporting only types ## Background The `consistent-type-exports` rule from TypeScript-ESLint helps improve code clarity and enables better tree-shaking by enforcing the use of `export type` syntax when exporting only type definitions. Reference: https://typescript-eslint.io/rules/consistent-type-exports/ ## Test Plan - [ ] Verify CI passes with the new test enabled - [ ] If tests fail, investigate the Go implementation at the rule implementation location - [ ] Fix any issues in the implementation to make tests pass - [ ] Ensure all existing tests continue to pass ## Notes This PR follows the same pattern as #156 which enabled the `consistent-indexed-object-style` rule test. The change itself is minimal - just uncommenting a single line - but CI will validate that the rule implementation is complete and correct. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
## Summary - Enable the test for the `default-param-last` rule by uncommenting line 46 in `packages/rslint-test-tools/rstest.config.mts` ## Background The `default-param-last` rule enforces that parameters with default values should appear last in function signatures, after all required parameters. This is consistent with TypeScript-ESLint's rule behavior. ## Implementation Status The rule is already fully implemented in Go: - Implementation: `internal/plugins/typescript/rules/default_param_last/default_param_last.go` - Go tests: `internal/plugins/typescript/rules/default_param_last/default_param_last_test.go` - TypeScript test file: `packages/rslint-test-tools/tests/typescript-eslint/rules/default-param-last.test.ts` The Go implementation handles: - Regular function declarations, expressions, and arrow functions - Class methods and constructors - Parameter properties (public/private/protected) - Optional parameters (`?`) - Rest parameters (`...`) - Destructuring parameters with defaults ## Test Coverage The test file includes comprehensive test cases for: - Valid code: parameters with defaults/optionals at the end - Invalid code: parameters with defaults/optionals before required parameters - Edge cases: parameter properties, destructuring, mixed scenarios ## References - TypeScript-ESLint rule: https://typescript-eslint.io/rules/default-param-last/ - Original ESLint rule: https://eslint.org/docs/latest/rules/default-param-last 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
## Summary - Uncommented the `consistent-return.test.ts` test file in `rstest.config.mts` (line 41) - This enables testing for the `consistent-return` rule implementation ## Context The `consistent-return` rule ensures that functions always return a value or never return a value consistently. This test was previously commented out and is now being enabled. ## Testing The CI will run the tests to verify the implementation passes all test cases. If tests fail, the rule implementation may need to be fixed or implemented from scratch. ## References - TypeScript-ESLint consistent-return rule: https://typescript-eslint.io/rules/consistent-return/ - Original ESLint consistent-return: https://eslint.org/docs/latest/rules/consistent-return 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
## Summary This PR enables the test for the `explicit-function-return-type` rule by: 1. Uncommenting the test file in `rstest.config.mts` (line 47) 2. Implementing the rule from scratch in Go 3. Registering the rule in the global rule registry ## Implementation Details The `explicit-function-return-type` rule enforces explicit return type annotations on functions and class methods in TypeScript code. This improves code clarity and can enhance type-checking performance in large codebases. ### Supported Configuration Options - `allowExpressions` (default: `false`) - Permits function expressions to skip return type declarations - `allowTypedFunctionExpressions` (default: `true`) - Ignores functions with type annotations on the variable assignment - `allowHigherOrderFunctions` (default: `true`) - Overlooks functions that directly return other functions - `allowDirectConstAssertionInArrowFunctions` (default: `true`) - Exempts arrow functions using `as const` assertions - `allowConciseArrowFunctionExpressionsStartingWithVoid` (default: `false`) - Allows arrow functions prefixed with `void` keyword - `allowFunctionsWithoutTypeParameters` (default: `false`) - Ignores non-generic functions - `allowIIFEs` (default: `false`) - Exempts immediately invoked function expressions - `allowedNames` (default: `[]`) - Array of specific function/method names to ignore ### Files Changed - `packages/rslint-test-tools/rstest.config.mts` - Uncommented test file - `internal/plugins/typescript/rules/explicit_function_return_type/explicit_function_return_type.go` - New rule implementation - `internal/config/config.go` - Rule registration ## Testing The implementation follows the TypeScript-ESLint specification and handles: - Function declarations - Function expressions - Arrow functions - Method declarations - Getter accessors - All configuration options from the spec ## References - TypeScript-ESLint rule documentation: https://typescript-eslint.io/rules/explicit-function-return-type/ - Test file: `packages/rslint-test-tools/tests/typescript-eslint/rules/explicit-function-return-type.test.ts` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
✅ Deploy Preview for rslint ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
1 participant
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.
Related Links
DevBird enabled many rules and adjusted the implementation to make the tests pass.
This is a PR to sync with https://github.com/kdy1/rslint
Checklist