Files
dspace-angular/lint
Yury Bondarenko e40b6ae612 Update plugins to support standalone components
- ThemedComponent wrappers should always import their base component. This ensures that it's always enough to only import the wrapper when we use it.
- This implies that all themeable components must be standalone

→ added rules to enforce this
→ updated usage rule to improve declaration/import handling
2024-03-28 18:33:46 +01:00
..
2024-03-21 10:11:04 +01:00

DSpace ESLint plugins

Custom ESLint rules for DSpace Angular peculiarities.

Documentation

The rules are split up into plugins by language:

Run yarn docs:lint to generate this documentation!

Developing

Overview

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)