Upstream coreutils changed `feat_wasm` from an explicit list of utilities
to `feat_wasm = ["feat_common_core", "nproc"]`. The workflow scraped that
list with a sed range, which cannot resolve feature groups and, now that
feat_wasm is a one-liner, ran on to the next `]` and swallowed the body of
feat_os_unix. The deployed commands.js ended up as
const WASM_COMMANDS = ["feat_Tier1","feat_common_core","feat_os_unix",
"feat_require_unix","feat_require_unix_utmpx","nproc","grep",...];
and since executeCommandLine() gates dispatch on that array, every
coreutils command answered "command not found" in the playground without
ever reaching the WASM binary, which was fine all along.
Replace the scrape with scripts/wasm-command-list.py, which resolves the
feature through the [features] table down to the leaf optional
dependencies (the utility crates), drops `dep:`/`crate/feat` entries,
strips the `uu_` prefix (uu_test -> test) and fails loudly if the feature
resolves to no utilities.
The unit tests stayed green through all of this because the test page only
loaded wasm-terminal.js and therefore always exercised FALLBACK_COMMANDS,
never the generated file. Load /wasm/commands.js there too and assert that
the core utilities are present and that no feature group leaks in; against
the currently deployed commands.js that now fails 72 of 185 tests instead
of passing. Also refresh FALLBACK_COMMANDS with the utilities feat_wasm
gained (hostid, mktemp, nice, test, tty).
feat_diagnostics only comes in through coreutils' default feature set, and
the playground binary is built with --no-default-features, so uucore
compiled diagnostics_stub.rs: enabled() was a hardcoded false and every
utility printed the plain one-line error. `expr 9 + foo` in the playground
showed no caret at all.
browser_wasi_shim reports stderr as a character device with FD_WRITE and
neither FD_SEEK nor FD_TELL, which is what Rust's WASI is_terminal() takes
for a tty, so the reports render once the feature is on.
Build the locate and updatedb binaries from uutils/findutils alongside
find and advertise them in the playground. The standalone WASM matrix now
takes a list of bins per module, emitting one .wasm per binary.
xargs is intentionally omitted: it must spawn child processes, which the
browser WASI sandbox does not support.
Add uutils/sed to the playground alongside grep, find and diff/cmp. sed
builds a single `sed` binary and, like diffutils, has only pure-Rust
dependencies (fancy-regex and regex, not onig), so its WASM build needs no
WASI SDK — it joins the wasm-standalone matrix with needs_wasi: false.
Register sed as its own on-demand standalone module (sed -> sed.wasm), add
it to the fallback command list, the help/load hints, a substitution
example, the version footer, and tests (stdin substitution, global
substitution over a file, and -n line selection).
The website workflow built all four WASM modules (uutils, grep, find,
diffutils) serially in a single job. Split them so they compile in
parallel: coreutils keeps its own job (it needs the l10n copy, locales.js
and feat_wasm command parsing), while grep/find/diffutils share one matrix
job (grep/find pull in onig_sys and need a WASI sysroot; diffutils is pure
Rust). Each leg uploads its .wasm plus numbered command/version fragments
that the build job stitches into commands.js / version.js; SITE_VERSION is
generated there since it describes the site repo. Add Swatinem/rust-cache
to every build to speed up warm runs.
Add uutils/diffutils to the playground alongside grep and find. The
diffutils binary is a multicall that provides diff and cmp, dispatched on
argv[0], so each command is invoked directly by name. Unlike grep/find it
has only pure-Rust dependencies (regex, not onig), so its WASM build needs
no WASI SDK.
Generalize the standalone-module registry from command->url to
module->{url, commands} so one module can back several commands: diff and
cmp share a single diffutils.wasm, load once on demand, and get one 'Load'
button. Add a couple of near-identical shopping-*.txt sample files so diff
and cmp have a small, readable change to show, plus a diff example, help
entry, version footer, and tests (diff/cmp exact-match; diff -u checked on
its hunk body, since its header carries an environment-dependent mtime).
Generalize the single-module grep handling into a registry of standalone
WASM modules so additional uutils tools can drop in. Add `find`, built from
uutils/findutils to wasm32-wasip1 in CI, with graceful degradation when the
binary is absent.
Only `find` is shipped: xargs/locate/updatedb need process spawning or an
on-disk database, neither of which works in the browser WASI sandbox.
Add an emoji `find . -name '*.md'` example backed by fruit-emoji files in the
virtual FS to show off Unicode/multibyte filename matching, plus tests.
The playground version line records the coreutils WASM commit and the
site commit, but grep (built as its own standalone WASM module) had no
provenance shown. Capture grep's commit/short/date in the workflow and
append a UUTILS_GREP_VERSION block to version.js, then render it next to
"Built from uutils/coreutils ..." as "grep <short> (<date>)" linking to
the uutils/grep commit.
grep ships as its own standalone WASM module (not part of the coreutils
multicall binary) and depends on the Oniguruma C library, so the website
workflow now checks out uutils/grep, installs the WASI SDK to provide a
wasm sysroot for the onig_sys C sources, builds grep.wasm, and appends
"grep" to the generated command list.
The terminal loads grep.wasm as an optional second module and dispatches
grep directly (argv[0] = "grep"). grep defaults to --color=never since the
WASI shim reports stdout as a TTY, which would otherwise emit match-
highlight escapes that corrupt piped output; explicit --color is honored.
Adds a grep emoji example and grep WASM integration tests.
Sylvestre Ledru
renovate[bot]