Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how to use the TSLint static inspection tool in the React Native project. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

TSLint provides code checking ability for TypeScript and plays an important role in standardization, security, reliability, maintainability and so on for React Native projects using TypeScript. The following is mainly about the sharing of TSLint-related knowledge and the introduction of custom TSLint rules.

Will you freak out when the established code specifications are not followed and there are different styles of code all over the project?

Programs that pass the test cases will also appear Bug, and the reason is only because of their own low-level mistakes, will you freak out?

When there is a problem with a code writing method that leads to a crash, you can only check the code throughout the project, which takes a lot of time to Review code, will you freak out?

The above problems can be effectively alleviated through static inspection!

Static check (Static Program Analysis) is mainly the technology of checking and analyzing the program source code without running the program, while the opposite is dynamic check (Dynamic Program Analysis), which produces the expected results by inputting test data into the actual running program. Through static checking of the code, we can quickly locate errors and defects in the code, reduce the time wasted in reading the code line by line, and quickly scan for possible vulnerabilities in the code. Code static checking can play an important role in the standardization, security, reliability and maintainability of the code.

In the client, Android can use tools such as CheckStyle, Lint, Findbugs, PMD, and iOS can use tools such as Clang Static Analyzer, OCLint, etc. In the development process of React Native, ESLint for JavaScript and TSLint for TypeScript have become the tools for static checking of the main code. This article will explore and analyze the reasons for using TSLint, the methods of using TSLint, and the steps of customizing TSLint.

1. Reasons for using TSLint

As the client team enters the development process of the React Native project, it faces the following problems:

As people transfer from the client to the React Native development process, they are prone to low-level syntax errors.

Developers were previously engaged in Android, iOS, front-end and other work, so the code style is different, resulting in different project code style.

The effect of the client is inconsistent. It is possible that the Android side shows normal, the iOS side shows an exception, or the opposite occurs.

Although the above problems can be alleviated by constantly marking out thunder points, constantly sharing experiences and strengthening the code Review process, we are still faced with problems such as the different technical levels mastered by React Native developers and the slow spread of knowledge sharing, which not only leads to the continuous increase of development costs and continuous low development efficiency, but also can not avoid the situation that a pit has been stepped on many times. There is an urgent need for a tool that can meet the following goals:

Can detect code low-level syntax errors

Standardize the project code style

You can customize the logic to check the code as needed.

Tool users can access and deploy to the development IDE environment "foolishly".

Can quickly and efficiently synchronize the latest check logic of the inspection tool to the development IDE environment

The problems detected can be located quickly.

According to the description of the above requirements, the static checking tool TSLint can achieve the goal more effectively.

II. Introduction to TSLint

TSLint is a project of Silicon Valley enterprise Palantir. It is a static checking tool that can check the readability, maintainability and functional errors of TypeScript code. Currently, many editors (Editors) and build systems (Build Systems) support this tool, while supporting custom writing Lint rules, configuration, formatting, and so on.

The current TSLint already contains hundreds of rules that form the basis of the current TSLint check. During the code development phase, these configured rules can give a complete check to the project and indicate possible problems at any time. The content of this article refers to the official TSLint document https://palantir.github.io/tslint/.

2.1 TSLint Common rules

The following rules are mainly derived from TSLint rules and are a brief introduction to some rules.

2.2 Common TSLint rule packages

The rules listed above are derived from the official Palantir TSLint rules. In fact, there are many more, and the following may be used:

In the process of configuring the rules of the project, we generally use one or more of the above rule packages to configure at the same time, so how to configure it? Please see below.

Third, how to configure and check TSLint rules

First, configure the TSLint package in the project package.json file:

You can configure existing rules as needed in the tslint.json file in the root directory, for example:

The inherited TSLint rule package is placed in the extends array. The above figure includes the rule package configured by airbnb and the rule package of tslint-react, while rules is used to configure the switch of the rule.

TSLint rules currently have only options for true and false, which results in either normal or error ERROR without warnings such as WARNING.

Sometimes, although some rules are enabled, some or all rule checks may be turned off in a file, which can be configured through rule comments, such as:

/ * tslint:disable * /

The above comments indicate that the TSLint rule check is turned off in all the following areas, starting from the line on which this comment is made.

/ * tslint:enable * /

The above comments indicate that the TSLint rule check is enabled in all the following areas starting from the line on which this comment is made.

/ * tslint:disable:rule1 rule2 rule3... , /

The above comments indicate that all the following areas close the rule rule1 rule2 rule3..., starting from the line on which this comment is located. Donovan's examination.

/ * tslint:enable:rule1 rule2 rule3... , /

The above comments indicate that the rule rule1 rule2 rule3... is enabled in all the following areas starting from the line on which this comment is located. Donovan's examination.

/ / tslint:disable-next-line

The above comment indicates that the next line on the line of this comment turns off TSLint rule checking.

SomeCode (); / / tslint:disable-line

The above comment indicates that the line on which this comment is located turns off TSLint rule checking.

/ / tslint:disable-next-line:rule1 rule2 rule3...

The above comment indicates that the next line of this comment is the closing rule rule1 rule2 rule3... Check it out.

For the above configuration information, please refer to https://palantir.github.io/tslint/usage/rule-flags/.

3.1 Local inspection

After completing the configuration of the project, you need to download the required dependency package, and use the npm install command to download the dependency package in the root directory where the project is located.

IDE environment hint

After downloading the dependency package, the IDE environment can prompt according to the corresponding configuration file and prompt the error message of the existing code in real time. Take VSCode as an example:

Local command check

At present, there is room for further improvement in VSCode. If some files are not open in the window, there may be errors that are not indicated. At this time, we can check the whole project through local commands, and execute them in the root directory of the React Native project through the following command line:

Tslint-project tsconfig.json-config tslint.json

(if this command does not run correctly, you can add. / node_modules/.bin/ before) that is:

. / node_modules/.bin/tslint-project tsconfig.json-config tslint.json

This prompts an error message similar to the following:

Src/Components/test.ts [1,7]: Class name must be in pascal case3.2 online CI check

The process of local code inspection will also have the possibility of being forgotten, through technical protection, can avoid artificial forgetting, as the standard process of code submission, through CI inspection and then merge the code, can effectively avoid the problem of code errors. The CI system can be understood as a cloud environment, and the configuration of the environment is consistent with that of the local environment. In this case, a report that is consistent with the local report can be generated. The Jenkins-based Castle CI system can be used within Meituan, and the generated results are consistent with the local results:

3.3 other ways

Code review is not limited to the above stages, but can be triggered in the code commit, pull request, packaging, and other stages.

In the code commit phase, the code check can be triggered by Hook, which can effectively force the online CI check phase to advance, which basically ensures the complete correctness of the online CI check.

In the code pull request phase, the code check can be triggered by the online CI check, which can effectively ensure the correctness of the merging branch, especially the main branch.

In the code packaging phase, the online CI check can trigger the code check, which can effectively ensure the correctness of the packaged code.

IV. Custom writing TSLint rules 4.1.Why customize TSLint rules

Although the current TSLint rules cover some code reviews that are more common problems, there are still some problems in practice:

The personalized needs in the team are difficult to meet. For example, asynchronous functions in saga need to add try-catch to the outermost layer, and exceptions need to be reported in the catch block, which is obviously impossible to implement in the official TSLint rules, which requires custom development.

The opening and configuration of official rules are not in line with the current team situation.

For the above reasons, other teams also have precedents for customizing TSLint, such as tslint-microsoft-contrib, tslint-eslint-rules, and so on.

4.2 Custom rule steps

What steps do you need to customize the TSLint? first, the rule file writes the rule information step by step according to the specification, then analyzes the syntax tree and writes the logic code according to the code inspection logic, which is also the core part of the custom rule, and finally the use of the custom rule.

Examples of custom rules refer directly to official rules, so we can refer to a relatively simple rule "class-name" here.

As mentioned above, the "class-name" rule means to standardize class naming. When the class-related naming in the team is not standardized, it will lead to non-uniform project code style and even other problems, and the "class-name" rule can effectively solve this problem. We can take a look at the specific source file: https://github.com/palantir/tslint/blob/master/src/rules/classNameRule.ts.

This custom rule is then explained step by step.

The first step is file naming

Rule naming must conform to the following 2 rules:

Name the hump.

Suffixed with 'Rule''.

The second step is class naming

The class name of the rule is Rule, and you want to inherit the type Lint.Rules.AbstractRule. Of course, there may be times when you inherit the class TypedRule, but we found that it also inherits from the class Lint.Rules.AbstractRule by reading the source code.

Step 3: fill in the metadata information

Metadata contains configuration parameters, information about rules, and definitions of configuration rules.

RuleName is the rule name. Using the kebab naming method, the class name is generally changed to the kebab naming format.

Description a brief description of the rules.

Detailed rule description of descriptionDetails.

The theoretical basis of rationale.

Options configuration parameter form, if not can be configured as null.

OptionExamples parameter example, if there are no parameters, there is no need to configure.

Whether typescriptOnly true/false is only applicable to TypeScript.

Whether the hasFix true/false has a repair method.

Whether requiresTypeInfo requires type information.

Introduction to optionsDescrition options.

The type of type rule.

There are four types of rules, which are "functionality", "maintainability", "style" and "typescript".

Functionality: for sentence problems and functional issues.

Maintainability: rules that are primarily code concise, readable, and maintainable.

Style: rules that maintain a basically uniform code style.

Typescript: prompt for TypeScript.

Step 4, define the error message

This is mainly the text that prompts when a problem is checked, and is not limited to the use of a static variable, but most official rules are written in this way, which is introduced here to prevent ambiguity.

Step 5, implement the apply method

Apply is mainly the core method for static checking, which checks the code by returning the applyWithFunction method or applyWithWalker. In fact, the main difference between the applyWithFunction method and the applyWithWalker method is that applyWithWalker can implement a custom IWalker class through IWalker. The difference is as follows:

The abstract class AbstractWalker that implements IWalker also inherits WalkContext

And this WalkContext is the internal implementation class of applyWithFunction mentioned above.

Step 6, syntax tree parsing

Both the applyWithFunction method and the IWalker implementation in the applyWithWalker method pass in the parameter sourceFile, which is equivalent to the root node of the file, and then traverses the entire syntax tree node through the ts.forEachChild method.

Here are two tools to view the AST syntax tree:

AST Explorer:

Https://astexplorer.net/

Corresponding source code:

Https://github.com/fkling/astexplorer

TypeScript AST Viewer:

Https://ts-ast-viewer.com/

Corresponding source code:

Https://github.com/dsherret/ts-ast-viewer

AST Explorer

Advantages:

In AST Explorer, you can highlight the AST syntax tree information corresponding to the selected code.

Disadvantages:

1. The corresponding version of the parser cannot be selected, resulting in a fixed version of the syntax tree code displayed.

two。 The syntax tree displays relatively little information.

TypeScript AST Viewer

Advantages:

1. The corresponding version of the parser can be selected dynamically:

two。 The information displayed in the syntax tree shows not only the corresponding numeric code, but also the corresponding actual information:

The corresponding kind information values for each version may change, but the corresponding enumeration names are fixed, as shown in the following figure:

Thus this tool can avoid frequently looking up the corresponding information according to its numerical value.

Disadvantages: can not highlight the code corresponding to the AST syntax tree area, positioning efficiency is low.

In summary, the analysis efficiency can be effectively improved by using the above two tools to locate the analysis at the same time.

Step 7, write the rule code

Use the ts.forEachChild method to traverse all the nodes of the syntax tree, and you can implement your own logic in the traversal method, where the node class is ts.Node:

Of course, Node is the base class of all nodes, and its implementation also includes Statement, Expression, Declaration, etc. Back to the beginning of the "class-name" rule, all of our declaration classes are mainly class and interface keywords, corresponding to ClassExpression, ClassDeclaration, and InterfaceDeclaration, respectively. We can see an one-to-one correspondence in the syntax tree through the AST syntax tree tool mentioned in the previous step.

In the rule code, it is mainly judged by two methods: isClassLikeDeclaration and isInterfaceDeclaration.

The corresponding methods of isClassLikeDeclaration and isInterfaceDeclaration can be found in the node.js file:

When judging the corresponding type, call the addFailureAtNode method to pass in the error message and the node, and of course, you can also call the addFailureAt and addFailure methods.

Finally, the writing of this rule is over, and one point is emphasized again, because the type code corresponding to each version may be different, so when judging kind, you must not directly use the numbers corresponding to each type.

Step 8, configure the rules to use

After completing the rule code, it is the file with the suffix ts, but the ts rule file actually uses the js file. In this case, we need to use the command to convert ts to js file:

Tsc. / src/*.ts-- outDir dist

Generate the ts rules to the dist folder (this folder is named and customized by the user), and then configure the generated rule file in the tslint.json file.

Then in the root directory of the project, you can check it using the following command:

Tslint-project tsconfig.json-config tslint.json

At the same time, in order to add new rules and better operability of rule configuration in the future, it is suggested that they can be encapsulated into their own rule package for the management and dissemination of rules.

Summarize the advantages of TSLint:

It's fast. Compared with dynamic code checking, the checking speed is faster. For existing projects, whether they are checked locally or in CI, a React Native project consisting of more than ten pages can be completed in 1 to 2 minutes.

Flexible. By configuring rules, common code errors and potential Bug can be effectively avoided.

Easy to expand. By writing custom rules for configuration, you can find out specific risk points in the code timely, accurately and quickly.

Disadvantages of TSLint:

The result of the rule is only right and wrong, and there is no prompt result of warning level.

The number of errors reported by rules cannot be reported directly and can only be counted by other means.

TSLint rules can effectively analyze and determine the current single file through the syntax tree, but it is difficult to determine the variables, classes and methods in other files referenced by the AST syntax tree.

Use results and analysis

In Meituan, after a single project with more than 10 pages was connected to TSLint for the first time, nearly 100 problems were detected. However, due to different open rules and different configuration rule packages, the number of checked rules may range from dozens to thousands or even more. More than a dozen custom rules have been developed to handle and optimize hundreds of potentially problematic code within a single project. Eventually TSLint was integrated into the relevant React Native development team and became a necessary step in the code submission phase.

Through the verification within the team, the problems encountered at the beginning of the article have been effectively alleviated, and the goal has basically met the expectations. In the process of React Native development, TSLint not only ensures the unity of code style, but also ensures the development quality of React Native developers, avoids many low-level errors, and effectively saves the cost of problem troubleshooting and personnel communication.

At the same time, using custom rules, we can summarize and prevent some personalized problems, including compatibility problems, improve the development efficiency, do not need to spend a lot of time to find the problem code, and avoid falling on a problem for many times. For developers with different experiences, they can not only provide friendly tips, but also help to quickly identify problems and spread the lessons learned from one person to other teams at a very low cost. evolve the development state from "mending the sheep after the sheep is lost" to "taking precautions".

The above is the editor for you to share the React Native project TSLint static check tool how to use, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.