Browser playground

These examples run the documentation build of the omena-wasm crate directly in your browser. Each section isolates one product workflow so that the source, result, and supporting evidence remain easy to connect.

Follow references across files

Omena evaluates CSS Modules references against the workspace rather than treating each stylesheet as an isolated string. The entry file below composes a selector and imports a value that its dependencies do not export.

.button {
  composes: missing from "./Base.module.css";
}

@value absent from "./Tokens.module.css";

Change missing to base and absent to accent, then analyze again. The underlines and Problems output clear only after both references resolve.

Build from workspace semantics

The same in-memory workspace can feed conservative transform passes. This example resolves @import and composes while preserving the exported class relationship and source-map origins.

@import "./tokens.css";

.button {
  composes: base;
  color: var(--brand);
}

.base {
  padding: 0.5rem 1rem;
}

Open Passes to see which transformations actually changed the source. A registered pass that makes no change is not presented as applied work.

Plan output for a browser target

Target queries select transformations from committed browser-support data. For IE 11, this example lowers light-dark(), scopes the CSS Module class, and adds the required flexbox prefix.

.card {
  display: flex;
  color: light-dark(#111, #eee);
}

Open Target plan to connect each output change to the pass that produced it. The complete target-data contract remains available in the collapsed raw output.

Browser boundary

These demonstrations are intentionally bounded to caller-supplied, in-memory files. Filesystem discovery, package-manager resolution, and editor lifecycle behavior belong to the CLI, NAPI, and LSP surfaces documented in SDK workflows.