Crates

The Rust workspace is defined in the top-level Cargo.toml:

[workspace]
resolver = "2"
members = ["crates/*"]

[profile.release]
lto = true

It contains four crates:

Crate	Path	What it does	Page
tailwindcss-oxide	crates/oxide/	The scanner + extractor.	oxide
tailwindcss-oxide (NAPI binding)	crates/node/	NAPI module published as @tailwindcss/oxide.	node
ignore (vendored)	crates/ignore/	Modified copy of BurntSushi's ignore used to walk a project.	(used internally by oxide)
classification-macros	crates/classification-macros/	Proc-macro crate that generates byte-classification lookup tables.	(used internally by oxide)

Why is the scanner Rust?

In v3 the scanner was JavaScript regex. v4 moved it to Rust because:

• The scanner is the hot path for incremental builds; it has to walk thousands of files quickly.
• A real grammar (state machines) makes language-specific extraction (Pug, Slim, Razor, Svelte, Vue, etc.) tractable. Regex would either be wildly inefficient or get the corner cases wrong.
• A NAPI binding gives the cost of one cross-language call per scan, which is amortizable.

Build

cargo build --release            # all crates
cargo build -p tailwindcss-oxide # just the scanner

The @tailwindcss/oxide npm package builds the NAPI binding via crates/node/build.rs and napi-build. The build emits a .node binary plus an index.js / index.d.ts shim that picks the right binary per platform. The crates/node/npm/ directory contains the per-platform stub packages (e.g. @tailwindcss/oxide-linux-x64-gnu) that ship those binaries.

Test

cargo test                          # everything
cargo test -p tailwindcss-oxide     # scanner only
cargo test -p tailwindcss-oxide -- --nocapture # show println!

Set RUST_LOG=tailwindcss_oxide=debug to enable tracing output (crates/oxide/src/scanner/init_tracing.rs).

Performance benchmarks

crates/oxide/src/throughput.rs and crates/oxide/fuzz/ exist for performance validation.