Angular 4中TSLint与Codelyser的实际应用及规则定制问询

Great question! These tools are absolute workhorses for Angular 4 development—let’s break down their value, how teams actually use them, and how you can tweak them to fit your project’s needs.

Practical Application Value #

First, why bother with these tools at all? Here’s what they bring to the table in real projects:

• Enforce consistent code style: No more arguing over where to put curly braces, how to name variables, or whether to use semicolons. TSLint locks in these conventions, so every team member’s code looks like it was written by the same person. This makes onboarding new devs way faster and code reviews far less tedious.
• Catch bugs early: TSLint flags issues like unused variables, accidental any type overuse, and unsafe type conversions before you even run your app. Codelyzer takes this a step further for Angular-specific gotchas—like trying to access a private component property directly in a template, or misusing Angular’s dependency injection.
• Enforce Angular best practices: Codelyzer is built specifically for Angular, so it knows all the framework’s do’s and don’ts. It’ll remind you to use proper selector naming for components/directives, avoid lazy-loading mistakes, and structure your modules the way Angular recommends.
• Boost long-term maintainability: By keeping code clean and consistent, these tools prevent technical debt from piling up. A year from now, you won’t look back at old code and wonder "what was I thinking?"

Real-World Usage Scenarios #

Teams don’t just run these tools once and forget—they integrate them into every stage of development:

• Local development (IDE integration): Most devs use VS Code or WebStorm with the TSLint plugin installed. As you write code, you’ll get real-time red squiggles for violations, and one-click fixes to auto-correct issues like incorrect indentation or missing semicolons. This saves tons of time during coding.
• Command-line checks: Run ng lint (Angular CLI includes TSLint/Codelyzer by default) to scan your entire project. This is perfect for catching issues you might have missed in the IDE, especially before committing code.
• CI/CD gatekeeping: Teams add ng lint to their continuous integration pipelines (like Jenkins, GitHub Actions, or GitLab CI). If the lint check fails—say, someone left an unused variable—the pipeline stops, and the code can’t be merged into the main branch. This ensures only clean, consistent code makes it to production.
• Code review support: Instead of wasting time nitpicking style issues in PRs, reviewers can focus on business logic and architecture. Just link the lint report in the PR, and everyone can see exactly what needs fixing.
• Incremental checks: When you’re working on a single component, run ng lint --files src/app/my-component/my-component.ts to only check that file. It’s way faster than scanning the whole project.

Customizing TSLint Rules #

Out-of-the-box rules are great, but you’ll often want to tweak them to fit your team’s preferences. Here’s how:

1. Modify Existing Rules #

Your Angular 4 project has a tslint.json file at the root—this is where all rules live. For example:

• To change your component selector prefix from app to my-app, find the component-selector rule and update it:

  "component-selector": [true, "element", "my-app", "kebab-case"]
  

• To turn off a rule you don’t need (like the no-console rule if your team uses console logs for debugging), set it to false:

  "no-console": false
  

2. Create Your Own Custom Rules #

If the default rules don’t cover your team’s specific needs, you can write a custom rule:

1. Create a custom-rules folder in your project root.
2. Add a TS file for your rule—for example, no-console-log.ts:

   import * as Lint from 'tslint';
   import * as ts from 'typescript';
   
   export class Rule extends Lint.Rules.AbstractRule {
     public static FAILURE_STRING = 'console.log is not allowed in production code';
   
     public apply(sourceFile: ts.SourceFile): Lint.RuleFailure[] {
       return this.applyWithWalker(new NoConsoleLogWalker(sourceFile, this.getOptions()));
     }
   }
   
   class NoConsoleLogWalker extends Lint.RuleWalker {
     public visitCallExpression(node: ts.CallExpression) {
       // Check if the call is to console.log
       if (node.expression.getText() === 'console.log') {
         this.addFailureAtNode(node, Rule.FAILURE_STRING);
       }
       super.visitCallExpression(node);
     }
   }
   

3. Update tslint.json to include your custom rules directory and enable the rule:

   {
     "rulesDirectory": "./custom-rules",
     "rules": {
       "no-console-log": true
     }
   }
   

4. Run ng lint—your custom rule will now scan all files and flag any console.log calls.

3. Customize Codelyzer Rules #

Codelyzer’s rules are also configurable in tslint.json. For example, to change your directive selector to use camelCase instead of kebab-case:

"directive-selector": [true, "attribute", "my-app", "camelCase"]

Overall, TSLint and Codelyzer aren’t just "nice-to-haves"—they’re essential tools to keep your Angular 4 codebase clean, consistent, and maintainable, especially as your team grows.

内容的提问来源于stack exchange，提问作者Shivani Gupta