mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-16 08:06:24 +03:00
Paul BakausandClaude Fable 5.1
1d214f1e48
An author who wants a rule off for one component has had two choices: put `data-impeccable-ignore` on every instance, or silence the rule (or the file) for the whole project. On impeccable-site #34 that meant eleven attributes on eleven copies of the same 10px label for `undersized-ui-text`, 25 opt-out attributes in all. The count is the problem: the markup carries noise, and the reviewer never sees how much was waived. `detector.ignoreSelectors` is the declared twin of that attribute. One entry, `{ rule, selector }`, waives the rule for every element the selector matches and for that element's subtree, the same waiver the attribute grants the element carrying it: impeccable ignores add-selector undersized-ui-text ".ks-tag" \ --reason "10px mono index labels, confirmed" The waiver is never silent. The engines stamp a waived finding with `ignoredBy: "<selector>"` instead of dropping it; the config layer drops and counts, and every scan prints one line per entry on stderr, in `--json` runs too, so stdout stays the findings array: 3 undersized-ui-text hits ignored by detector.ignoreSelectors on .ks-tag. Where it applies: the browser engine (`BrowserConfig.ignoreSelectors`, also readable from `window.__IMPECCABLE_CONFIG__`), the static HTML engine (`DetectHtmlOptions.ignore_selectors`, and the `ignoreSelectors` option of the wasm `detect_html_source_json` export), the detect CLI, and the design hook. The text engine has no DOM and ignores the key. Entries can be scoped with `files` globs like `ignoreValues`; `--no-config` disables them; `doctor` validates their rule ids alongside `ignoreRules`. Nothing changes for a project without the key: the engines stamp nothing, the CLI prints nothing, the config writer does not add an empty `ignoreSelectors`, and the per-instance attribute keeps working exactly as before. Coverage: `crates/html/tests/selector_ignores.rs` (component, subtree, wrong-rule, `*`, attribute parity), driver tests over the fake DOM, `crates/detect` config tests (normalize, merge, per-target narrowing, the tally), and oracle cases `detect-selector-ignore-*` / `ignores-selector-*` over a new workspace. The eight re-recorded context/doctor goldens differ only in the recognized-detector-keys sentence, which now lists the new key. Assisted-by: Claude Code Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LQBUunp8QttxZqihybNmtL
25 lines
1.1 KiB
Rust
25 lines
1.1 KiB
Rust
//! impeccable-core: the rule logic of the impeccable detector engine, ported
|
|
//! from the JS `cli/engine` with byte-for-byte behavioral parity. The
|
|
//! `check_*` / `scan_*` functions and the heuristics behind them live here.
|
|
//!
|
|
//! Everything they are written against lives in `impeccable-foundation`: JS
|
|
//! number and string semantics, colour maths, the rule registry, inline
|
|
//! ignores, the DOM probe trait, and the plain-data input and output types.
|
|
//! This crate re-exports those modules for its own convenience, so
|
|
//! `crate::js`, `crate::color`, `crate::browser::dom` and friends keep
|
|
//! resolving inside it, and so consumers can name everything through
|
|
//! `impeccable_core::`. No filesystem, process, or network access lives here,
|
|
//! and the crate compiles to wasm (`crates/wasm` builds the in-page bundle
|
|
//! and the extension core from it).
|
|
|
|
pub mod browser;
|
|
pub mod checks;
|
|
|
|
pub use impeccable_foundation::{
|
|
color, constants, fdlibm_trig, findings, fonts, inline_ignores, js, js_ext_a, js_ext_b, page,
|
|
registry, rule_pack, selector_ignores,
|
|
};
|
|
|
|
#[cfg(any(test, feature = "vectors"))]
|
|
pub mod vectors;
|