mirror of
https://github.com/DSpace/dspace-angular.git
synced 2025-10-07 01:54:15 +00:00
3937be13f2
The following cases are covered:
- ThemedComponent wrapper selectors must not start with ds-themed-
- Base component selectors must start with ds-base-
- Themed component selectors must start with ds-themed-
- The ThemedComponent wrapper must always be used in HTML
- The ThemedComponent wrapper must be used in TypeScript _where appropriate_:
- Required
- Explicit usages (e.g. modal instantiation, routing modules, ...)
- By.css selector queries (in order to align with the HTML rule)
- Unchecked
- Non-routing modules (to ensure the components can be declared)
- ViewChild hooks (since they need to attach to the underlying component)
All rules work with --fix to automatically migrate to the new convention
This covers most of the codebase, but minor manual adjustment are needed afterwards
2.1 KiB
2.1 KiB
ESLint plugins
Custom ESLint rules for DSpace Angular peculiarities.
Overview
- Different file types must be handled by separate plugins. We support:
- 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)