dc1053e3f9
We could turn these rules off, but it seems that they indicate some important inconsistencies.
A few cases have been ignored inline because they should be investigated in more detail, which is out of scope for this PR:
- Metadata representation components compare `BrowseByDataType` to a `ResourceType`. Could be related to #2949.
- We assume that dynamic form dates are always represented by strings, but they can also be `Date` or `object` according to the library (see da1742ce05/projects/ng-dynamic-forms/core/src/lib/model/dynamic-date-control.model.ts (L5))
DSpace ESLint plugins
Custom ESLint rules for DSpace Angular peculiarities.
Documentation
The rules are split up into plugins by language:
Run
yarn docs:lintto 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.jsonfiles 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
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
ThemedComponentwrapper 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
- Retrieve all
- This only needs to happen once, and only takes a fraction of a second (for ~100 themeable components)