Describe the feature you'd like:
Today @testing-library/jest-dom depends on the css.escape npm package. In current versions (e.g. 6.9.x), usage appears limited; notably in to-have-form-values, where values are interpolated into [name="…"] selectors for querySelectorAll, which requires correct CSS escaping.
We’d like the library to prefer the standard CSS.escape API when it exists in the test environment (e.g. globalThis.CSS?.escape), and only use a polyfill when the supported Node / Jest / jsdom matrix actually requires it, ideally allowing the standalone css.escape dependency to be dropped or made optional.
Motivation (supply chain): The standalone css.escape package’s latest release is still 1.5.1, published in August 2016 there has been no new release in roughly a decade, which creates maintenance / policy pressure for downstream consumers even when the implementation is “small” and widely used transitively. Reducing or removing this dependency (by using native CSS.escape where the supported test environment allows) would address that without changing matcher behavior for typical users.
There is also existing reports about the polyfill’s side effects (e.g. #469).
Suggested implementation:
- At module init or call site: use
typeof globalThis.CSS !== 'undefined' && typeof globalThis.CSS.escape === 'function' (or equivalent) and call CSS.escape(name) when building the selector; otherwise fall back to current behavior.
- Alternatively, if the project’s minimum jsdom guarantees
CSS.escape, remove the css.escape package entirely and document the requirement.
(Exact placement should match where escape is imported today — e.g. to-have-form-values.)
Describe alternatives you've considered:
Teachability, Documentation, Adoption, Migration Strategy:
- Docs: Add a short note under installation or “environment requirements” if a minimum jsdom / Node is required for the no-polyfill path.
- Migration: If the change is backward-compatible (native when present, polyfill fallback), no test code changes for consumers; if the polyfill is removed entirely, document the minimum environment and bump semver appropriately per project conventions.
Related: #469 (polyfill / window.CSS interaction).
Describe the feature you'd like:
Today
@testing-library/jest-domdepends on thecss.escapenpm package. In current versions (e.g. 6.9.x), usage appears limited; notably into-have-form-values, where values are interpolated into[name="…"]selectors forquerySelectorAll, which requires correct CSS escaping.We’d like the library to prefer the standard
CSS.escapeAPI when it exists in the test environment (e.g.globalThis.CSS?.escape), and only use a polyfill when the supported Node / Jest / jsdom matrix actually requires it, ideally allowing the standalonecss.escapedependency to be dropped or made optional.Motivation (supply chain): The standalone
css.escapepackage’s latest release is still1.5.1, published in August 2016 there has been no new release in roughly a decade, which creates maintenance / policy pressure for downstream consumers even when the implementation is “small” and widely used transitively. Reducing or removing this dependency (by using nativeCSS.escapewhere the supported test environment allows) would address that without changing matcher behavior for typical users.There is also existing reports about the polyfill’s side effects (e.g. #469).
Suggested implementation:
typeof globalThis.CSS !== 'undefined' && typeof globalThis.CSS.escape === 'function'(or equivalent) and callCSS.escape(name)when building the selector; otherwise fall back to current behavior.CSS.escape, remove thecss.escapepackage entirely and document the requirement.(Exact placement should match where
escapeis imported today — e.g.to-have-form-values.)Describe alternatives you've considered:
window.CSS#469: That issue is focused on a specific polyfill bug; this request is broader (dependency reduction + native API), so a separate feature issue is clearer.Teachability, Documentation, Adoption, Migration Strategy:
Related: #469 (polyfill /
window.CSSinteraction).