build(swc): enable Wasm benchmarks (jantimon#24)

- Migrate to workspace to allow testing in isolation
- Add benchmarks

Author: martindisch

swc/Cargo.lock

@@ -1,10 +1,8 @@
-[package]
-name = "swc-plugin-css-variable"
-version = "0.1.0"
-edition = "2021"
-
-[lib]
-crate-type = ["cdylib"]
+[workspace]
+members = [
+    "swc-plugin-css-variable",
+    "transform",
+]
 
 [profile.release]
 # Uncomment to achieve smallest possible binary size (may require more experimentation).
@@ -13,23 +11,3 @@ crate-type = ["cdylib"]
 # codegen-units = 1
 # lto = true
 # opt-level = "z"
-
-[dependencies]
-serde = {version="1.0.152", features = [
-	"derive",
-]}
-serde_json = "1.0.91"
-swc_core = {version = "0.58.0", features = [
-	"ecma_plugin_transform",
-	"ecma_ast",
-	"common",
-]}
-pathdiff = "0.2.1"
-regex = "1.7.1"
-lazy_static = "1.4.0"
-xxhash-rust = { version = "0.8.6", features = ["xxh32"] }
-base62 = "2.0.2"
-
-[dev-dependencies]
-swc_ecma_parser = "0.124.2"
-swc_ecma_transforms_testing = "0.119.0"

swc/Cargo.toml

@@ -0,0 +1,51 @@
+# swc-plugin-css-variable
+
+This is the SWC counterpart to the babel plugin of this library.
+
+## Structure
+
+This is a workspace with two crates:
+
+- `swc-plugin-css-variable` is the outer shell and only contains what's
+  necessary to interface with SWC, which is essentially the main function that
+  is decorated with `#[plugin_transform]`
+- `transform` has everything else, most importantly the visitor implementation
+
+The reason for the split is to enable benchmarking inside Wasm runtimes. If the
+code under test (the visitor) were in the same crate as `#[plugin_transform]`,
+code would be generated that requires functions to be linked in for accessing
+the environment and emitting diagnostics. Normally these are provided at
+runtime by SWC, but for only running benchmarks we don't want to have to
+fake them.
+
+## Benchmarking
+
+The benchmarks can be run easily with `cargo bench`. Note that this builds and
+runs native code on your machine, which may not exhibit the exact same
+performance characteristics as a Wasm module in a runtime, as is the case for
+SWC transformations.
+
+To account for this, it's also possible to build a benchmark executable in Wasm
+format and execute it in your runtime of choice. Since SWC internally uses
+[Wasmer](https://wasmer.io), it makes sense to install this one. Then, it's
+just a matter of
+
+```console
+$ cargo build --bench bench_main --release --target wasm32-wasi
+# Get the name of the Wasm module we just built
+$ ls -t target/wasm32-wasi/release/deps/*.wasm | head -n 1
+target/wasm32-wasi/release/deps/bench_main-9530540cc15e2e67.wasm
+# Execute the benchmark
+$ wasmer target/wasm32-wasi/release/deps/bench_main-9530540cc15e2e67.wasm -- --bench
+```
+
+With this you get the most accurate runtime behavior and can observe the
+difference to native code. However, you'll most likely find it negligible, with
+Wasm being just slightly slower and everything else scaling mostly linearly. A
+typical example:
+
+- `wasmer: visitor styledPage      time:   [6.6177 µs 6.6316 µs 6.6495 µs]`
+- `native: visitor styledPage      time:   [5.4191 µs 5.4736 µs 5.5150 µs]`
+
+For most changes that aren't Wasm-specific, it's therefore often good enough to
+just run the benchmarks normally with `cargo bench`.

swc/README.md

@@ -0,0 +1,17 @@
+[package]
+name = "swc-plugin-css-variable"
+version = "0.1.0"
+edition = "2021"
+
+[lib]
+# cdylib is for dynamic system library and necessary to produce the Wasm plugin
+crate-type = ["cdylib"]
+
+[dependencies]
+lazy_static = "1.4.0"
+pathdiff = "0.2.1"
+regex = "1.7.1"
+serde_json = "1.0.91"
+swc_core = { version = "0.58.0", features = ["ecma_plugin_transform"] }
+
+transform = { path = "../transform" }