feat: Implement TypeScript-ESLint no-restricted-types rule

[delino]

Summary

Implements the TypeScript-ESLint no-restricted-types rule for rslint, which disallows certain types based on configuration.

Implementation Details

Rule Implementation

• Location: internal/plugins/typescript/rules/no_restricted_types/no_restricted_types.go
• Language: Go
• Full implementation with configurable type restrictions
• Supports custom messages for each restricted type
• Allows fix suggestions where applicable

Features

✅ Restrict types with boolean true for default message
✅ Restrict types with custom string messages
✅ Restrict types with object configuration (message and fixWith fields)
✅ Support for namespace-qualified types (e.g., NS.Banned)
✅ Support for generic types (e.g., Banned<any>, Banned<A,B>)
✅ Support for empty tuples [] and empty objects {}
✅ Normalization of type names (whitespace trimming)

Testing

• Test File: packages/rslint-test-tools/tests/typescript-eslint/rules/no-restricted-types.test.ts
• All test cases ported from the original TypeScript-ESLint repository
• Test enabled in packages/rslint-test-tools/rstest.config.mts

Changes Made

1. Created rule implementation in Go
2. Registered rule in internal/config/config.go
3. Ported all test cases from TypeScript-ESLint
4. Enabled test in rstest.config.mts

Documentation & References

• Rule Documentation: https://typescript-eslint.io/rules/no-restricted-types/
• TypeScript-ESLint GitHub: https://github.com/typescript-eslint/typescript-eslint
• Original Test Cases: https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/tests/rules/no-restricted-types.test.ts

Example Configuration

{
  "@typescript-eslint/no-restricted-types": [
    "error",
    {
      "types": {
        "String": {
          "message": "Use string instead",
          "fixWith": "string"
        },
        "{}": {
          "message": "Use object instead",
          "fixWith": "object"
        }
      }
    }
  ]
}

Testing

The implementation includes all original test cases from the TypeScript-ESLint repository, covering:

• Simple type restrictions (string, number, boolean, etc.)
• Empty tuples and objects
• Custom messages and fix suggestions
• Qualified names (NS.Type)
• Generic types (Type)

🤖 Generated with Claude Code

[kdy1]

🤖 This pull request has been linked to DevBird Task #1598

View the task details and manage the automated development workflow in DevBird.

Learn more about DevBird here or the announcement blog post here.

[kdy1]

📋 DevBird Task Prompt

Implement the TypeScript-ESLint no-restricted-types rule for rslint.

Objective: Create a complete implementation that disallows certain types.

Documentation & Resources:

• Rule documentation: https://typescript-eslint.io/rules/no-restricted-types/
• TypeScript-ESLint GitHub: https://github.com/typescript-eslint/typescript-eslint
• Original test cases: https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/tests/rules/no-restricted-types.test.ts

Implementation Requirements:

1. Copy all test cases from the original TypeScript-ESLint repository test file
2. Implement the rule from scratch with configurable type restrictions
3. Support custom messages for each restricted type
4. Allow fix suggestions where applicable

Testing Requirements:

1. Port all valid and invalid test cases from the original repository
2. Test various type restrictions
3. Test custom messages
4. Enable the test in packages/rslint-test-tools/rstest.config.mts by uncommenting the line:
   './tests/typescript-eslint/rules/no-restricted-types.test.ts'

Success Criteria:

• Rule restricts configured types
• Custom messages work
• All original test cases pass
• Test is enabled in rstest.config.mts

---

This comment was automatically added by DevBird. You can disable this feature in DevBird Settings.

[claude]

Code Review: TypeScript-ESLint no-restricted-types Rule Implementation

Thank you for implementing this rule! I've conducted a thorough review of the code quality, architecture, testing, and integration. Overall, this is a well-implemented feature that follows the codebase conventions closely.

---

✅ Strengths

Code Quality & Best Practices

• Excellent pattern consistency: mirrors the existing ban_types rule pattern
• Proper nil safety: Every AST node conversion is followed by nil checks (lines 82-84, 90, 97)
• Clean separation of concerns: Helper functions are well-extracted and focused
• Good code comments: Complex logic is well-documented
• Fallback strategy: Proper fallback to source text extraction (lines 194-197)

Robust Options Parsing

• Dual-format support correctly implemented (lines 29-44)
• Type normalization: Whitespace trimming on type names (line 49)
• Flexible configuration: Supports bool, string, and object configurations

Comprehensive Test Coverage (35 test cases)

• All primitive types (bigint, boolean, never, null, number, object, string, symbol, undefined, unknown, void)
• Empty tuples and objects
• Qualified names (NS.Banned)
• Generic types (Banned, Banned<A,B>)
• Nested structures and various type contexts
• Whitespace normalization edge cases
• Fix suggestions with fixWith option

Proper Integration

• Config registration correct in internal/config/config.go
• Alphabetical ordering maintained
• Test enabled in rstest.config.mts

---

🔍 Areas for Improvement

1. Generic Type Matching Logic (Potential Edge Case)

Location: no_restricted_types.go:154-165

The code generates "Banned<A,B>" (no space) but test line 604 expects it to match config 'Banned<A, B>' (with space).

Action needed: Please confirm the Banned<A,B> test (line 604) actually passes.

2. Message Formatting (Minor)

Location: no_restricted_types.go:116

When customMessage is empty, the message ends with a period and nothing else. When customMessage has content, there's no space between the period and the custom message.

3. Missing Documentation (Minor)

The rule implementation file lacks a package-level comment explaining what the rule does.

---

Security & Performance

✅ Security: No concerns identified. Input validation is implicit through Go's type system.

✅ Performance: Looks good with O(1) lookup, early returns, and efficient AST traversal (only 3 node kinds).

---

Test Quality: 9.5/10

Comprehensive coverage with good edge cases. Minor gap: No tests for null/false config values that allow types.

---

📋 Final Checklist

• ✅ Code follows codebase patterns
• ✅ Proper error handling and nil checks
• ✅ Comprehensive test coverage
• ✅ Config registration correct
• ✅ No security vulnerabilities
• ✅ Good performance characteristics
• ⚠️ Generic type matching needs verification
• ⚠️ Message formatting could be cleaner (minor)
• ⚠️ Missing package-level documentation (minor)

---

🎯 Recommendation: APPROVE with minor suggestions

This is a solid implementation that follows the codebase patterns well. The code is production-ready.

Action items:

1. Required: Confirm the Banned<A,B> test passes
2. Optional: Improve message formatting
3. Optional: Add package-level documentation

Great work overall! The implementation is clean, well-tested, and integrates properly with the existing codebase.

[claude]

Code Review: TypeScript-ESLint no-restricted-types Rule Implementation

Summary

This PR implements the no-restricted-types rule for rslint, which allows disallowing certain TypeScript types based on configuration. The implementation is well-structured and closely follows the repository's established patterns.

✅ Strengths

1. Good Code Structure: The implementation follows the same patterns as similar rules in the codebase (e.g., ban_types, no_this_alias)
2. Comprehensive Feature Coverage: Supports all required configurations (boolean, string, and object formats with message and fixWith)
3. Proper Nil Handling: Correctly handles nil checks throughout with early returns
4. Good Documentation: Well-commented code with clear explanations of each section
5. Consistent Registration: Properly registered in internal/config/config.go with alphabetical ordering maintained

🔍 Issues & Concerns

1. Critical: Inconsistent Qualified Name Handling

Location: internal/plugins/typescript/rules/no_restricted_types/no_restricted_types.go:166-187

The getIdentifierOrQualifiedName function handles qualified names differently than the similar ban_types rule:

• no_restricted_types: Returns full qualified path (e.g., NS.Banned)
• ban_types: Returns only the root identifier (e.g., NS)

Impact: This is actually correct for no-restricted-types (which should match full qualified names like NS.Banned), but creates an inconsistency in the codebase. This is acceptable given different rule semantics, but should be documented.

Recommendation: Add a comment explaining why qualified names are handled differently from ban_types.

2. Potential Bug: Message Formatting Issue

Location: internal/plugins/typescript/rules/no_restricted_types/no_restricted_types.go:113-116

When customMessage is not empty, there's no space separator before it. This results in messages like:

• "Don't use String as a type.Use string instead"

Expected:

• "Don't use String as a type. Use string instead"

3. Code Quality: Missing Constant for Message ID

The string "bannedTypeMessage" is used directly. Consider defining it as a package constant for consistency.

4. Inconsistency: Different Message Format from ban_types

• ban_types: Uses the custom message directly if provided, otherwise generates default
• no_restricted_types: Always prepends "Don't use X as a type" even when custom message exists

This means the same configuration will produce different messages in the two rules.

🎯 Performance Considerations

1. Efficient Map Lookup: Using map[string]RestrictedTypeConfig for O(1) lookup is optimal ✅
2. String Normalization: Done at configuration time, not during checking ✅
3. AST Traversal: Only registers listeners for relevant node types ✅

🔒 Security Considerations

No security concerns identified:

• No user input is executed or eval'd ✅
• No file system operations ✅
• No external network calls ✅
• Proper bounds checking on all array/slice accesses ✅

✅ Test Coverage

The PR description indicates all test cases from TypeScript-ESLint are ported, which is excellent.

📝 Recommendations Summary

Must Fix

1. Fix message spacing issue (Issue chore: update rule-manifest.json [auto] #2)

Should Fix

2. Add comment explaining qualified name handling difference
3. Consider extracting message ID constant
4. Add whitespace trimming for extracted type names

Nice to Have

5. Align message format with ban_types for consistency
6. Add inline comment explaining generic type format without spaces

Overall Assessment

This is a solid implementation that demonstrates good understanding of the codebase patterns. The main issue is the message formatting bug that should be addressed before merging. Otherwise, the code is production-ready with comprehensive test coverage.

Rating: 7.5/10 (would be 9/10 after fixing the message spacing issue)

---

🤖 Generated with Claude Code