dspace-angular/lint/README.md

DSpace ESLint plugins

Custom ESLint rules for DSpace Angular peculiarities.

Documentation

The rules are split up into plugins by language:

• TypeScript rules
• HTML rules

Run yarn docs:lint to generate this documentation!

Developing

Overview

• All rules are written in TypeScript and compiled into dist
  • The plugins are linked into the main project dependencies from here
  • These directories already contain the necessary package.json files to mark them as ESLint plugins
• The plugins are declared in .eslintrc.json. Individual rules can be configured or disabled there, like usual.
• Some useful links
  • Developing ESLint plugins
  • Custom rules in typescript-eslint
  • Angular ESLint

Parsing project metadata in advance ~ TypeScript AST

While it is possible to retain persistent state between files during the linting process, it becomes quite complicated if the content of one file determines how we want to lint another file. Because the two files may be linted out of order, we may not know whether the first file is wrong before we pass by the second. This means that we cannot report or fix the issue, because the first file is already detached from the linting context.

For example, we cannot consistently determine which components are themeable (i.e. have a ThemedComponent wrapper) while linting. To work around this issue, we construct a registry of themeable components before linting anything.

• We don't have a good way to hook into the ESLint parser at this time
• Instead, we leverage the actual TypeScript AST parser
  • Retrieve all ThemedComponent wrapper files by the pattern of their path (themed-*.component.ts)
  • Determine the themed component they're linked to (by the actual type annotation/import path, since filenames are prone to errors)
  • Store metadata describing these component pairs in a global registry that can be shared between rules
• This only needs to happen once, and only takes a fraction of a second (for ~100 themeable components)