known-css-properties

known-css-properties exports a single JSON-backed array of CSS property names — both W3C standard properties and vendor-prefixed variants (-webkit-, -moz-, -ms-, and older -o-/-wap-/-epub- prefixes) collected from real browser support data. Property names are extracted from the W3C spec index at various maturity levels (REC, CR, LC, WD, FPWD, ED) and cross-referenced against dozens of recorded Chrome, Firefox, Safari, Edge, Internet Explorer, Opera, Samsung Internet, and UC Browser versions going back over a decade, so the list reflects properties that browsers have actually implemented, not just what specs describe.

The project ships no runtime logic beyond a one-line require — the value is entirely in the curated, deduplicated, sorted dataset. A Renovate-driven update pipeline (scripts/download-w3c-data.mjs and scripts/generate.mjs) periodically refreshes the underlying source JSON and regenerates data/all.json, so consumers like CSS linters, autocomplete tooling, and static analyzers can check property names against current reality without maintaining their own list.

What You Get

• all export - A flat, deduplicated, alphabetically-grouped array of every known CSS property name (standard + vendor-prefixed).
• W3C-sourced coverage - Properties pulled from the W3C CSS all-properties index across REC, CR, LC, WD, FPWD, and ED maturity levels.
• Vendor-prefix coverage - Prefixed variants (-webkit-, -moz-, -ms-, -o-, -epub-, -wap-) captured from real getComputedStyle/document.body.style probes across dozens of browser versions.
• TypeScript types - Ships an index.d.ts declaring all as string[] for type-safe consumption.
• Automated refresh pipeline - download-w3c-data.mjs and generate.mjs scripts, wired to Renovate, keep the dataset current as new CSS properties and browser versions ship.

Common Use Cases

• CSS linter property validation - Linting tools check whether a declared property name is real before flagging typos or unsupported values.
• Editor/IDE autocomplete - Language servers and CSS-in-JS tooling use the list to power property-name autocomplete and suggestions.
• Static analysis of generated CSS - Build tools verify that dynamically generated or templated CSS only emits recognized property names.
• Cross-browser compatibility auditing - Tools cross-reference the list against a target browser matrix to flag properties unsupported outside the standard set.

Under The Hood

Architecture index.js is a one-line facade that requires the static data/all.json blob and re-exports its properties field as all. The actual complexity lives in the build-time pipeline, entirely decoupled from the published artifact: scripts/download-w3c-data.mjs fetches the W3C CSS all-properties feed and per-browser support snapshots into source/w3c.json, source/unknown.json, and roughly four hundred individual source/browsers/<name>-<version>.json files, and scripts/generate.mjs reads all of them, flattens and deduplicates the combined property lists with lodash, sorts them using a regex that strips vendor prefixes for grouping, and writes the merged result to data/all.json. Because only the generated JSON ships, changing the merge/sort logic has zero runtime blast radius for consumers — the architecture is a static-data package with an offline ETL script as its only real engineering surface.

Tech Stack Plain Node.js: the generation scripts are ES modules (.mjs) while the published entry point is CommonJS (index.js). Dev-only dependencies are globby (glob-based file discovery across the ~400 browser source files) and the single-function lodash.sortby/lodash.uniq modules for dedup and custom sorting; eslint 8.57 lints the two published JS files. There is no build step for the package itself, no server or database component, and no CI configuration visible in the repository — Renovate handles dependency and data-source upkeep, and the release flow is a manual npm version patch && npm publish.

Code Quality There are no test files anywhere in the repository — package.json’s test script is a literal echo "Error: no test specified" && exit 1 — so there is no automated verification that the generated property list is correct or that the generation script behaves as expected on malformed source data. The two runtime-relevant files (index.js, index.d.ts) are minimal and easy to read; the generation script has no explicit error handling and assumes every source JSON file parses cleanly. ESLint is configured for style enforcement, but there is no type checking of the JavaScript source and no CI evidence to confirm lint or any check runs automatically on changes.

API Design The public API is as minimal as it gets — a single named export, all, typed via a hand-written index.d.ts as string[] — so integration requires no configuration, no async initialization, and no options object; consumers just import the array and use standard array operations against it. That minimalism is also the whole design limitation: there is no way to filter to only standard properties, only vendor-prefixed ones, or only properties supported by a specific browser version, even though the underlying source/browsers/*.json files clearly contain that per-browser granularity — it is collapsed into one undifferentiated list before publish. Documentation is a single README code snippet with no dedicated docs site or JSDoc on the export, so understanding data provenance means reading the generation script directly.