Danny Kim
2.0 KiB
description
| description |
|---|
| Apps use the npm lint plugins' configs, port their old deno-lint-plugin.ts rules into scripts/project-lint.ts, never override source files, and refactor instead of raising limits |
Plugins
Apps consume the published plugins as npm devDependencies, through jsPlugins
and the configs equivalent to what their Deno setup enabled:
@cunarist/eslint-plugin-explicit-types:concrete,naming,absence@cunarist/eslint-plugin-import-check:import-check@cunarist/eslint-plugin-lit:core,strict,dom-ref,reactive-controller,naming
Repo-local rules
The local scripts/deno-lint-plugin.ts that home, eximium, stockvibe, brain,
memona, and memona-home carried is ported into scripts/project-lint.ts
(project-lint-plugin) under the project namespace, same rule names and
behavior. Depending on the repo: no-self-sync, no-sync-in-render,
app-module-conventions, always-wildcard-export, no-class-extends,
no-lit-nothing, no-title-attribute, prefer-wa-components,
no-satisfies, no-unknown, restricted-types, no-line-lint-ignore,
no-app-disposables-in-component, no-crepe-react-ui. @hugoalh rules map to
Oxlint built-ins in configs.project.
memona's deno-lint-plugin.ts and its coding-standards memory are the house
style the explicit-types rules came from; they win any conflict.
No overrides, refactor instead
Apps use no overrides for source files at all (the rule-registry
exception exists only in plugin repos). Oxlint's default limits stay, and
violations are refactored without behavior change in the same PR: barrels for
max-dependencies, splits for max-lines/max-lines-per-function/
max-classes-per-file, an options object for max-params. Long Lit
render() templates are split into smaller template functions or
components. See lint-overrides-policy.
If a hand-written exception still looks truly necessary, ask the user first; when they're away, leave it failing or refactor, and log the question.