Add ts-standard static analysis tool

[anthony-tom1]

Proof of Installation

• ts-standard was installed through running the command npm install ts-standard
• The following screenshots show the terminal output when running npm install ts-standard

• The following screenshot shows the line change made in package.json. Within the dependencies field, a new "ts-standard" field was added with the value "^12.0.2" indicating the minimum version number.

Artifacts

• ts-standard was run through the terminal command npx ts-standard > ts_standard_output.txt 2>&1
• Terminal output was redirected to the text file ts_standard_output.txt (attached below)
  • ts_standard_output.txt.zip
• Standard errors were redirected to the same location as standard outputs through 2>&1
• The following screenshot shows the output of terminal commandnano ts_standard_output.txt after ts-standard is run.

Pros and Cons of ts-standard

• Pros:
  • ts-standard provides detailed recommendations for consistent formatting, including punctuation and spacing. These recommendations enable the codebase to have improved readability and style.
  • For each issue, ts-standard provides a concise message (e.g. "Extra semicolon.", "Unexpected tab character."), enabling faster pinpointing of problems within the codebase.
  • When running the terminal command npx ts-standard --fix to display file changes, there are 870 files changed, 122502 insertions, and 122793 deletions. These values demonstrate the extensive ability of ts-standard in fixing a high quantity of linting and formatting issues.
    • Note that git restore . was run afterward to ensure that the codebase remained unchanged from this evaluation.
  • The a priori customization process was simple, only requiring the creation of a tsconfig.json file (TypeScript configuration file) through the command npx tsc --init. No additional customization was required over time as ts-standard was used.
• Cons:
  • The output in ts_standard_output.txt is 280,452 lines long. This high quantity of content makes manual inspection and evaluation difficult and time-consuming.
  • Projects without a TypeScript configuration file (including our NodeBB project) require a longer setup process with the creation of a tsconfig.json file. The ability to use the ts-standard tool strictly depends on the existence of this TypeScript configuration file.
  • ts-standard is limited in functionality and cannot be utilized for evaluating and improving deeper quality metrics like cyclomatic complexity, test coverage, and architectural quality.

[marcuswu5]

Everything looks good, I think you should submit this pr without ts_standard_output.txt and add it as an attachment instead

[marcuswu5]

Looks good to me!

[anthony-tom1]

Tool Name: ts-standard

Tool Description

ts-standard is a linter and automatic code fixer that is a TypeScript equivalent of StandardJS. ts-standard automatically formats code, ensuring code style consistency. ts-standard can catch style issues and programmer errors early. ts-standard utilizes ESLint with the eslint-config-standard-with-typescript sharable configuration, reducing the amount of configuration overhead through fewer required extra dependencies.

Source: https://github.com/standard/ts-standard

Type of Analysis: Static Analysis

Problems Caught by ts-standard

ts-standard catches style issues (e.g. extra and unexpected punctuation and whitespace), enabling it to enforce code style consistency. ts-standard also catches programming-related errors (e.g. undefined names), reducing the time and effort needed to debug and fix code. These issues are mostly related to formatting, syntactic, and semantic problems. ts-standard utilizes the ESLint set of rules to identify formatting issues in the program.

Customization

The a priori customization process was simple, only requiring the creation of a tsconfig.json file (TypeScript compiler configuration file) through running the terminal command npx tsc --init. This tsconfig.json file determines the root files and compiler options required to compile the project, as stated by the TypeScript documentation. Additional customization may be required over time as project development needs become more clear.

Integration into Development Process

In order to integrate ts-standard into the development process, complete the following steps. First, access the top-level package.json file in the NodeBB codebase. Next, in package.json, update the “lint” script of the “scripts” field with the value “ts-standard” (currently set to eslint --cache ./nodebb .). This results in npm run lint running the equivalent of npx ts-standard. ts-standard will act as the program linter, reading and catching style and programming issues. Then, below the “lint” field, add a “lint:fix” script with the value “ts-standard --fix”. This field uses the --fix command-line flag, modifying the codebase by automatically fixing caught style and programming issues. This results in npm run lint:fix running the equivalent of npx ts-standard --fix. ts-standard will act as the program linter, reading and catching style and programming issues. The "scripts" field will then contain the following scripts (excluding other scripts of the root script field):
{"scripts": {"lint": "ts-standard", "lint:fix": "ts-standard --fix"}}

If there are files that should be ignored by the ts-standard linter, a separate root “ts-standard” field can be created with the “ignore” subfield. Include a list of the folders and files to ignore in the “ignore” subfield.
Example (excluding other root fields of package.json): {“ts-standard” : {“ignore”: [“build/”, “node_modules/”, “test/”]}}
The command npm run lint is a core component of the development workflow, enabling for the maintenance of code style consistency and program functionality. Setting ts-standard as the main linter integrates the ts-standard tool into the development workflow effectively.

ts-standard is useful and should be integrated into the development process, as it can fix style issues and programming-related errors for both JavaScript and TypeScript files. ts-standard enforces code style consistency, improving code readability and organization. ts-standard can also catch errors early, reducing time and effort needed to fix code errors and bugs.

Reflection on False Positives, False Negatives, Unnecessary True Positives

ts-standard has a specified set of rules for code style formatting. The set of style formatting rules are derived from the ESLint documentation. Examples of rules include 2-space indentation, no extra semicolons and parentheses, and no trailing whitespace at the end of lines. ts-standard strictly enforces these formatting rules. As a result, no false positives were observed. However, there is always a possibility of false positives, where specific formatting choices seem off but are necessary. These formatting rules may conflict with developer intentions and preferences (e.g. some developers may want to include tabs instead of spaces).

It is important to note that ts-standard is limited to basic static analysis and is not ideal for detecting deeper logical errors, so ts-standard should be used alongside other tools. These limitations can lead to ts-standard missing deeper programming errors, resulting in potential false negatives.

The true positives that were provided in the ts-standard output were important and necessary for the development process. This is likely because the information provided by ts-standard provides useful insight into the specific formatting issues within the program (e.g. unexpected punctuation, inconsistent spacing, undefined variables). These formatting issues (especially with spacing) can be overlooked by developers, so these issue reports are significant to the development workflow and process.