wf

A command-line tool for looking up web platform features. Search by keyword, check Baseline status, find MDN docs, specs, browser bugs, survey results, and more, from your terminal.

Where the data comes from

wf combines two open data sources maintained by the W3C WebDX Community Group:

• web-features: the canonical catalogue of web platform features, including names, descriptions, specifications, Baseline status, and browser support versions.
• web-features-mappings: extended metadata that maps each feature to MDN docs, Web Platform Tests, Chrome status entries, browser bugs, developer surveys, standards positions, usage counters, and Interop project participation.

Both datasets are updated frequently (often daily). wf fetches the latest data at runtime so you always get current results.

Install

Requires Node.js 18+.

npm install -g web-features-cli

To update to the latest version:

npm update -g web-features-cli

See the web-features-cli package on npm.

Usage

wf <query> [options]

Search for features

wf fetch
wf "container queries"
wf grid

Searches match against feature IDs, names, descriptions, spec URLs, caniuse IDs, and BCD compatibility keys. Results are ranked by relevance.

Choose what to display

By default, wf shows Baseline status and browser support. Use -s / --show to pick specific sections (repeatable):

wf fetch -s baseline -s docs
wf grid -s bugs -s positions
wf flex -s surveys -s usage

Available sections:

| Section | Description | |-------------|-------------------------------------| | baseline | Baseline status and browser support | | spec | Specification links | | docs | MDN documentation links | | tests | Web Platform Tests links | | bugs | Browser bug tracker links | | surveys | State of CSS/JS/HTML survey data | | signals | Developer signals (votes) | | positions | Standards positions (vendor stances)| | usage | Chrome usage counters | | chrome | Chrome feature status entries | | interop | Interop project data |

Use --all / -a to show every section at once:

wf "container queries" --all

Other options

| Flag | Description | |------|-------------| | -n, --limit <n> | Maximum number of results (default: 20) | | -f, --full | Expand truncated lists (bugs, surveys, etc.) | | -l, --list | Print all feature IDs | | -u, --update | Force refresh the cached data | | --no-color | Disable colored output | | -h, --help | Show help |

Examples

Look up a feature by exact ID:

wf fetch

Search with multiple words:

wf "container queries" -s baseline -s docs

Show everything about CSS grid:

wf grid --all -n 1

Check bugs and standards positions:

wf "view transitions" -s bugs -s positions

Expand all truncated lists:

wf fetch -s bugs --full

List all known feature IDs:

wf --list

How search works

Queries are matched against multiple fields with weighted scoring:

• Exact feature ID match (highest priority)
• Partial feature ID match
• Exact or partial name match
• Description match
• Spec URL match
• BCD compatibility key match
• Caniuse ID match

Results are sorted by score, so the most relevant features appear first.

How it stays up to date

wf does not bundle any data. On each run, it fetches the latest data from:

• unpkg.com/web-features@next/data.json
• raw.githubusercontent.com/web-platform-dx/web-features-mappings/main/mappings/combined-data.json

Responses are cached locally in ~/.cache/wf/ for 24 hours. After that, the next run silently re-fetches fresh data in the background. If you're offline, the stale cache is used as a fallback.

To force a refresh at any time:

wf --update

You never need to reinstall or update the wf package itself to get new data.

Publishing a release

Publishing to npm is fully automated via GitHub Actions. Pushing a Git tag that starts with v triggers the publish workflow, which sets the package version from the tag and runs npm publish.

Steps

1. Create and push a tag:

   git tag v1.2.0
   git push origin v1.2.0

2. The workflow extracts the version from the tag (e.g. v1.2.0 → 1.2.0), writes it into package.json, and publishes to npm.

Notes

• The tag must match the pattern v* (e.g. v1.2.0, v2.0.0-beta.1).
• The version in package.json on main is a placeholder; the real version always comes from the git tag at publish time.

License

MIT