capybara-simulated 0.0.7 → 0.1.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 3d7b5f908d1c75a41fabf90b90c779ae21813de6a4620a7b574e4dfca69134cf
-  data.tar.gz: 57ddffb46aca509cd981106c4ac0ad421d38956c52fba5d439add59ae2e10aab
+  metadata.gz: c645fc942083807ecc024135e4bde092fa7859628346a14bac9d4423ab04a99f
+  data.tar.gz: b52e0d0c5ce4755653e457e25abcaa0e12735edb25f98e89ebd73f666617088b
 SHA512:
-  metadata.gz: 576d88b9d8fe7d0c480e8ad7309e7861d9be563a95ab992f6d870f66c06a12d0255f779622ac25e7bab19aa7c6868bf929593e31fe146b4b3fe4d01e3447a37b
-  data.tar.gz: 8cfe9a00eff04e4df4d8aa3b1938f122001a00bc7e15f0f3c5b92975fd51c82b2d115aa9b5031ead063a236e4b4c81159ec9d947ea7e5df948e165d5047f3055
+  metadata.gz: b82c3e7db9b6024a4eaa3fae041083a6b298d72a6be826412b9b2825622ae6e02d2eff73ef864f33546bf6f763ace0da0e1c24c10dfe4255808a1447fc952293
+  data.tar.gz: 3da1582f39042d4f9c4789aee9db645318eccb7f0ef0393b4d39045cf3e94163459b51ba75f9a029716e0951532a9d056a711ccf78b9c73b752cd256cef46802

data/README.md

@@ -1,123 +1,69 @@
 # capybara-simulated
 
-A lightweight Capybara driver that runs JavaScript in a long-lived
-[mini_racer](https://github.com/rubyjs/mini_racer) V8 context against a
-[happy-dom](https://github.com/capricorn86/happy-dom) DOM. XPath queries
-are powered by [Wicked Good XPath](https://github.com/google/wicked-good-xpath).
-
-The goal is the middle ground between `rack-test` (zero JS) and full
-headless browsers like cuprite/selenium: in-process tests, no Chrome,
-inline `<script>` and event handlers run, the Capybara DSL works, and
-forms submit through `Rack::MockRequest`.
+A lightweight Capybara driver that runs JavaScript against an
+in-process JS-resident DOM, with no Chrome. Forms submit through
+`Rack::MockRequest`, inline `<script>` and event handlers run,
+MutationObserver / custom elements / `<template>` / Shadow DOM /
+Trix / Stimulus / Turbo all work, and the Capybara DSL is unchanged.
+
+The DOM lives entirely inside the JS engine — V8 via
+[rusty_racer](https://github.com/ursm/rusty_racer) or QuickJS via
+[quickjs.rb](https://github.com/hmsk/quickjs.rb), whichever is
+installed — with no Nokogiri tree on the Ruby side. Capybara finds
+resolve through css-select (CSS) and xpathway (XPath) running in the
+same context as the page's JS, so `find` / `has_css?` / `within` see
+exactly the tree the app sees.
 
 ## Status
 
-Used in production by a Rails 8 app to run ~200 `js: true` system specs
-without spawning a headless Chrome.
-
-Against Capybara 3.40's shared `Capybara::SpecHelper.spec` suite the
-driver passes **1335 / 1357 examples** with 0 failures and 22 pending,
-once the unsupported-capability tags `about_scheme`, `css`, `download`,
-`frames`, `hover`, `screenshot`, `scroll`, `server`, `spatial`, `windows`
-are filtered out. The 22 pending all need capabilities the driver
-intentionally does not implement:
-
-- 19 `#drag_to` tests — Dragula / SortableJS / jsTree resolve drop
-  targets through `elementFromPoint(clientX, clientY)`, which needs a
-  real layout engine with stacking-context awareness.
-- 1 `#click should not retry clicking when wait is disabled` — depends
-  on the same `elementFromPoint`-based obscured-element detection.
-- 2 unrelated upstream-pending specs.
-
-`evaluate_async_script` is supported by polling the Ruby↔V8 bridge while
-draining the virtual clock until the user callback fires (or
-`Capybara.default_max_wait_time` elapses). Click offsets and `Element#drop`
-work without a real layout engine: click x/y are resolved into clientX/Y
-by walking computed `top`/`left`/`width`/`height` (px only, ancestor-sum)
-on the way out of the runtime.
-
-### Turbo + Stimulus (Rails)
-
-The driver targets Rails apps using importmap-rails + Turbo + Stimulus
-out of the box:
-
-- `<script type="importmap">` is parsed; `<script type="module">` and
-  every reachable `import` are pre-fetched through the Rack app and
-  bundled on the fly via `node vendor/js/bundle-modules.mjs` (a small
-  esbuild driver). The resulting IIFE is evaluated in the same isolate
-  as inline scripts and shares the same happy-dom Window.
-- `fetch` is replaced with a Rack-routed implementation: cookies follow
-  the jar, `X-CSRF-Token` propagates, redirects are followed up to 20
-  hops, and `Response`/`Headers`/`Request`/`AbortController` come from
-  happy-dom. WebSocket / EventSource / Action Cable broadcasts are out
-  of scope — use Selenium for those flows.
-- Custom-element upgrade is patched at `customElements.define` to
-  rebuild the document's id-element index — happy-dom 20's auto-upgrade
-  leaves the original (un-upgraded) element in the index, so
-  `getElementById('records')` after a Turbo Stream `<turbo-frame>` swap
-  would otherwise return a detached ghost.
-- Click on `<button type="submit">` lets happy-dom auto-dispatch the
-  `submit` event with the proper `submitter` field; we capture whether
-  the event was preventDefaulted and skip our own redundant submit
-  dispatch. Without this, Turbo's `FormSubmitObserver` saw a second
-  submitter-less event and intercepted forms whose submitter had
-  `data-turbo="false"`.
-- Page-level globals (`addEventListener`, `MutationObserver`,
-  `requestAnimationFrame`, `CustomEvent`, `getComputedStyle`,
-  `IntersectionObserver` stub, etc.) are mirrored from the active
-  Window onto `globalThis` so module bundles running at the top level
-  find them without going through `window.*`.
-- happy-dom's `MutationObserverListener` keeps its dispatch callback in
-  a `WeakRef`, with no other strong reference. V8 collects the arrow
-  before the next mutation fires, so `target[mutationListeners]` still
-  carries the listener but `callback.deref()` returns undefined and
-  every record (and every subtree-propagation hop on `appendChild`) is
-  silently dropped — Stimulus loses sight of buttons added inside a
-  swapped `<turbo-frame>`. We patch `MutationObserver.prototype.observe`
-  per Window to swap each WeakRef out for a strong-reference shim with
-  the same `.deref()` shape, so listeners survive the next GC.
-- happy-dom 20's `Attr` class doesn't override `Node.nodeValue`, which
-  the [DOM spec](https://dom.spec.whatwg.org/#dom-node-nodevalue)
-  defines as the attribute's `value`. The default getter inherited
-  from `Node` returns `null`, so any XPath engine reading attribute
-  string-values via `nodeValue` (wgxpath included) collapses every
-  attribute compare to `"null" === "null"` and predicates like
-  `[@id = //label/@for]` match every element with any `@id`. We install
-  a per-Window `Attr.prototype.nodeValue` getter / setter that mirrors
-  `value`.
-
-WebSocket, frames and multi-window remain explicitly out of scope — they
-need a real browser (Selenium / Cuprite) or a separate transport that
-this driver does not provide.
-
-The V8 isolate is created once per `Capybara::Simulated::Browser` instance
-and reused across all visits and resets — only the happy-dom `Window` is
-torn down between specs. This keeps `reset!` cheap.
-
-## Build
+The architecture and behaviour are stable. Correctness is held to two
+bars. A vendored subset of
+[web-platform-tests](https://github.com/web-platform-tests/wpt) — the
+same DOM / HTML tests Chromium and Firefox hold themselves to — runs as
+a conformance gate. And each target app (Redmine / Forem / Avo /
+Mastodon / Discourse) runs its full system suite against the driver in
+[capybara-simulated-vs-world](https://github.com/ursm/capybara-simulated-vs-world)
+as an integration check.
 
-```
-npm install
-npm run build         # produces vendor/js/csim.bundle.js (~2.9MB)
-bundle install
-bundle exec rspec
-```
+The remaining gaps need a real layout engine (`elementFromPoint`,
+truthy `getBoundingClientRect`, viewport-clip visibility, `display:
+contents` table edge cases) — the same set Selenium escapes via
+screenshots and this driver deliberately doesn't simulate.
 
 ## Install
 
-Add to your Gemfile (development / test group):
+```ruby
+gem 'capybara-simulated', group: :test
+gem 'rusty_racer', group: :test  # JS engine — pick one
+```
+
+`bundle install`. Requires Ruby ≥ 3.3. The gem ships its JS bridge
+under `lib/capybara/simulated/js/` and the vendored JS deps under
+`vendor/js/`, so there's no Node toolchain at consume time.
+
+### JS engine
+
+The gem treats the JS engine as a soft dependency. Pick one of:
 
 ```ruby
-gem 'capybara-simulated', '~> 0.0', group: :test
+gem 'rusty_racer'         # V8 (JIT, fastest per spec) — default
+gem 'quickjs', '>= 0.18'  # QuickJS (interpreter, smaller per-VM RAM —
+                          # wins when scaling parallel workers under
+                          # a fixed memory budget)
 ```
 
-Then `bundle install`. The gem ships its own pre-built happy-dom bundle
-under `vendor/js/`, so no `npm install` is required at consume time.
+The V8 engine comes from [rusty_racer](https://github.com/ursm/rusty_racer),
+a rusty_v8-based Ruby binding with the native ES Module API,
+`ScriptCompiler::CachedData` snapshots, and per-frame realm contexts the
+driver builds on.
+
+The engine is auto-detected at boot; if both gems are present V8 wins.
+Override explicitly with `CSIM_JS_ENGINE=v8|quickjs`
+or `Capybara::Simulated::Driver.new(app, js_engine: :quickjs)`.
 
 ## Use
 
-`require 'capybara/simulated'` registers the `:simulated` driver. The
-snippets below are minimal — drop them into your existing test bootstrap.
+`require 'capybara/simulated'` registers the `:simulated` driver.
 
 ### RSpec
 
@@ -127,12 +73,12 @@ require 'capybara/rspec'
 require 'capybara/simulated'
 
 Capybara.javascript_driver = :simulated
-# Optional: make :simulated the default for non-JS specs too.
+# Optional: use :simulated for non-JS specs too.
 # Capybara.default_driver = :simulated
 ```
 
-Tests tagged `js: true` (or `type: :system, js: true` in Rails) will run
-in the simulated driver:
+Tests tagged `js: true` (or `type: :system, js: true` in Rails) run
+in the driver:
 
 ```ruby
 RSpec.describe 'sign-in', type: :system, js: true do
@@ -146,11 +92,9 @@ RSpec.describe 'sign-in', type: :system, js: true do
 end
 ```
 
-For a Rails system test, set the driver in `before_setup` /
-`driven_by`:
+For Rails system tests, set the driver via `driven_by`:
 
 ```ruby
-# spec/system/sign_in_spec.rb
 RSpec.describe 'sign-in', type: :system do
   before { driven_by :simulated }
   # ...
@@ -160,8 +104,7 @@ end
 ### Minitest
 
 `Capybara.javascript_driver` is RSpec-only — `ActionDispatch::SystemTestCase`
-ignores it and `Capybara::Minitest::Test` has no `js: true` metadata
-mechanism. Set the driver explicitly:
+ignores it. Set the driver explicitly:
 
 ```ruby
 # test/application_system_test_case.rb
@@ -173,24 +116,6 @@ class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
 end
 ```
 
-(For pure `Capybara::Minitest::Test` outside Rails, set
-`Capybara.default_driver = :simulated` in your test_helper.)
-
-```ruby
-# test/system/sign_in_test.rb
-require 'application_system_test_case'
-
-class SignInTest < ApplicationSystemTestCase
-  test 'logs the user in' do
-    visit '/login'
-    fill_in 'Email',    with: 'alice@example.com'
-    fill_in 'Password', with: 'hunter2'
-    click_button 'Log in'
-    assert_text 'Welcome, Alice'
-  end
-end
-```
-
 ### Plain Capybara DSL (no framework)
 
 ```ruby
@@ -207,34 +132,254 @@ click_link 'About'
 puts page.text
 ```
 
-## How it fits together
-
-- `vendor/js/prelude.js` — minimal Web Platform polyfills (TextEncoder,
-  atob/btoa, crypto.getRandomValues, performance, timers, process).
-- `vendor/js/csim.bundle.js` — bundled happy-dom + whatwg-url +
-  Wicked Good XPath. Built via `build.mjs` with esbuild, with shims
-  for the Node built-ins happy-dom imports (`url`, `buffer`, `vm`,
-  `path`, etc.).
-- `vendor/js/runtime.js` — driver glue exposed on `globalThis.__csim`.
-  Manages the active happy-dom `Window`, an integer→DOM-node handle
-  table, modal capture, form serialization, click/submit dispatch, and
-  XPath through `document.evaluate` (installed by wgxpath). Fast-paths
-  Capybara's hot xpath shapes (`:option`, `:select`, `:link_or_button`)
-  to native `querySelectorAll` + `getElementById`.
-- `vendor/esbuild-wasm/` — vendored copy of esbuild-wasm so the gem can
-  bundle Rails importmap modules without a runtime npm dependency.
-- `lib/capybara/simulated/browser.rb` — owns the `MiniRacer::Context`,
-  drives HTTP via `Rack::MockRequest`, fetches `<script src>` inline,
-  and routes form submissions back through Rack.
-- `lib/capybara/simulated/{driver,node}.rb` — Capybara `Driver::Base` and
-  `Driver::Node` implementations.
+## Trace
+
+Each Capybara action (`visit`, `click`, `set`, …) is recorded as a step
+in a per-test trace: URL before / after, console output and network
+requests during the step, plus elapsed and per-step durations. On
+action failure (and only then, by default) the post-action DOM is
+captured too.
+
+Recording is **on by default** — fully in-memory, no files written
+unless you opt in via `CSIM_TRACE_DIR`. Wall-time overhead is
+run-to-run-variance equivalent because the expensive part — DOM
+serialization — only fires on action error.
+
+### Modes (`CSIM_TRACE=…`)
+
+| value | recording | DOM snapshot |
+|---|---|---|
+| (unset) / `on-failure` | yes (default) | per step on action error only |
+| `full` | yes | after every action — debug-heavy |
+| `off` | nothing recorded, `record_action` early-exits | — |
+
+### Inspecting traces
+
+In an after-hook:
+
+```ruby
+after(:each) do |example|
+  if example.exception
+    trace = page.driver.current_trace
+    puts trace.steps.last.dom_after  # final-state HTML
+    puts trace.steps.flat_map(&:console).map {|c| "#{c[:severity]} #{c[:message]}" }
+  end
+end
+```
+
+### File output
+
+Set `CSIM_TRACE_DIR=/path/to/dir` to enable file output. The bundled
+RSpec hook ([`csim_rspec.rb`](https://github.com/ursm/capybara-simulated-vs-world/blob/main/support/csim_rspec.rb))
+writes `<example slug>.json` into that directory after each test;
+mirror it in `application_system_test_case.rb`'s teardown for
+Minitest.
+
+```sh
+CSIM_TRACE_DIR=tmp/csim-traces bundle exec rspec spec/system
+```
+
+The metadata block on each trace includes `title`, `file`, `outcome`
+(`passed` / `failed`), and the exception message — enough to index a
+CI artifact directory by failure.
+
+### Programmatic
+
+For finer control, call `driver.start_tracing(...)` /
+`driver.stop_tracing(path: ...)`. The shape mirrors
+`capybara-playwright-driver`:
+
+```ruby
+RSpec.describe 'flaky payment flow', type: :system, js: true do
+  it 'completes a checkout' do
+    page.driver.start_tracing(case_id: 'PAY-1431')
+    visit '/checkout'
+    fill_in 'Card', with: '4242424242424242'
+    click_button 'Pay'
+    expect(page).to have_text 'Thank you'
+  ensure
+    page.driver.stop_tracing(path: "tmp/traces/#{example.full_description}.json")
+  end
+end
+```
+
+### Trace JSON schema
+
+```jsonc
+{
+  "version": 1,
+  "metadata": { "title": "...", "outcome": "passed", "...": "..." },
+  "steps": [
+    {
+      "index":       0,
+      "kind":        "visit",       // visit / click / set / send_keys / select / submit / refresh / go_back / go_forward
+      "description": "visit /checkout",
+      "url_before":  null,
+      "url_after":   "http://www.example.com/checkout",
+      "dom_after":   null,          // populated only on action error or in `full` mode
+      "console":     [{ "severity": "info", "message": "Stripe.js loaded" }],
+      "network":     [{ "method": "GET",    "url": "/checkout", "status": 200 }],
+      "elapsed_ms":  0,
+      "duration_ms": 38,
+      "error":       null
+    }
+  ]
+}
+```
+
+## Performance characteristics
+
+The driver builds a base snapshot once per process — the bundled
+bridge plus the vendored JS deps, as a V8 `Snapshot` for rusty_racer or
+bytecode for QuickJS. On V8 that snapshot warms a single long-lived
+isolate whose context is reset to a clean realm per navigation
+(`Context#reset`); on QuickJS each navigation checks a freshly
+snapshot-loaded VM out of a small pre-warmed pool. Either way, every
+navigation lands on a clean, warm JS context near-instantly.
+
+**Wall time is sensitive to whether the app uses Turbo Drive**,
+because navigation simulates real-browser semantics:
+
+| navigation source | what happens |
+|---|---|
+| `visit(...)`, `refresh`, programmatic `location.assign` | full reload — fresh JS Context, scripts re-evaluated |
+| link click *with Turbo Drive loaded* | Turbo intercepts, body-swap via JS, **JS context preserved** |
+| link click *without Turbo Drive* | full reload (anchor default action) |
+| form submit *with Turbo Drive loaded* | Turbo intercepts (turbo-frame or page-level), body-swap |
+| form submit *without Turbo Drive* | full reload |
+
+So Turbo Drive apps stay fast even with click-heavy tests; non-Turbo
+apps pay full-reload cost per click — exactly mirroring what the
+production site does.
+
+### Library snapshot policy
+
+Per visit, `<script src>`-referenced libraries (jQuery, Stimulus,
+…) re-evaluate fresh against the new page. They are **not** baked
+into a per-app snapshot — preserving library state across page
+navigations is what real browsers don't do, and trying to do it
+broke `$.ready` Callbacks queues whose user-app callbacks
+referenced page-specific DOM.
+
+### Other factors
+
+- **`<script src>` parsing** dominates `visit` on JS-heavy pages.
+  Each external script is fetched through the in-process Rack app,
+  compiled, and run in the JS engine with bytecode cache hits from
+  the base snapshot warmup.
+- **CSS cascade resolution**: stylesheets are parsed once per distinct
+  set of sources and cached content-addressably, so repeat visits and
+  subsequent finds on the same page reuse the resolved cascade instead
+  of re-parsing.
+- **DOM ops stay inside the JS engine** — find / has_? / event
+  dispatch never cross the Ruby ↔ JS boundary for the actual tree
+  walk; only the resulting handle ids do. Modify-heavy tests
+  (SortableJS dragging thousands of items) run at JS-engine speed,
+  not at host-call-IPC speed.
+- **Polling** (Capybara `default_max_wait_time`) advances a *virtual*
+  JS clock — timers fire as polling steps the clock forward, not in
+  real time. A page that schedules `setTimeout(2000, x)` doesn't block
+  for 2 s; the callback fires once polling has advanced the clock past
+  it.
 
 ## Known limits
 
-- happy-dom is not a layout engine — `visible?` is heuristic
-  (`display:none`, `visibility:hidden`, `hidden` attribute, head/script).
-- No fetch/XHR. `<script src>` is inlined via `Rack::MockRequest`. Real
-  navigation only happens on link click and form submit.
-- `evaluate_async_script`, frames, multi-window, file uploads, screenshots,
-  CSS computed-style filters, scroll/drag pixel coordinates are out of
-  scope.
+- **No layout engine.** `visible?` and `Node#style` consult the CSS
+  cascade and the inline `style` attribute, but
+  `getBoundingClientRect()` returns zeros and `elementFromPoint()`
+  isn't implemented. Click offsets work for fixture-style absolute /
+  relative positioning (ancestor-summed `top`/`left`); position-via-
+  layout (Dragula drops, sticky-header scroll math) needs a real
+  browser.
+- **`:hover` / `:focus-within`-gated content** is reachable two ways:
+  call `element.hover` explicitly (we track the most-recently-hovered
+  element and propagate `:hover` up its chain), or rely on the
+  candidate-chain fallback (when stateless cascade reports
+  `display: none`, we re-evaluate with the candidate itself in the
+  `:hover` set). Symmetric peers — N rows each with `tr:hover .icon`
+  revealing `.icon`, queried as bare `find('.icon')` — reveal all and
+  Capybara raises `Capybara::Ambiguous`. Scope the test (`find('tr',
+  text: 'foo').hover` then `find('.icon')`) — also more robust
+  against real-browser flake.
+- **`fetch` is synchronous-via-Rack** — HTML / JSON round-trips work
+  but there's no real network, no streaming, no `Request#body`
+  ReadableStream, and no concurrent requests. XHR is implemented
+  with the same Rack pass-through.
+- **Multi-window** is URL-tracking only — `target="_blank"` clicks
+  open a window-handle and `current_window` / `switch_to_window`
+  work, but each aux window only records its URL (no per-window JS
+  context or cross-window `postMessage`).
+- **`within_frame`, WebSocket, screenshots, and drag pixel
+  coordinates** are out of scope — use Selenium / Cuprite. There's no
+  frame-switching DSL to drive a test into an `<iframe>`, though an
+  iframe's own scripts do run, in a per-frame JS realm. (EventSource
+  and Web Workers *are* implemented.)
+
+## Architecture
+
+- `lib/capybara/simulated/js/src/` — the entire DOM lives here, split
+  across ~50 ES modules bundled into `bridge.bundle.js` (esbuild; no
+  Node toolchain at consume time). `Document` / `Element` / `Text` /
+  `DocumentFragment` / `ShadowRoot` classes; event dispatch
+  (capture / target / bubble with shadow retargeting, via
+  `dispatchEvent(target, event)`); a virtual `setTimeout` /
+  `setInterval` / `requestAnimationFrame` clock; MutationObserver;
+  custom-element registry; `Range` / `Selection`; and the cascade
+  resolver for `display` / `visibility` / `text-transform`. Capybara's
+  finds run through the vendored css-select (with css-what / css-tree)
+  for CSS and xpathway for XPath — both true third parties under
+  `vendor/js/`, executing in the same context as the page's JS.
+- `lib/capybara/simulated/browser.rb` — Rack client, history stack,
+  modal handler queue, virtual-clock anchor, trace recorder. Owns
+  the JS runtime via `V8Runtime` or `QuickJSRuntime`. The hot
+  operations (`find_css` / `find_xpath` / DOM ops / event dispatch)
+  are single-`Context#call` round-trips returning handle id arrays;
+  per-result iteration stays Ruby-side.
+- `lib/capybara/simulated/v8_runtime.rb` / `quickjs_runtime.rb` —
+  per-engine wrappers, common bits in `runtime_shared.rb`. The V8
+  base-snapshot (and the QuickJS bytecode equivalent) bakes in the
+  bundled bridge + vendored deps, so a per-navigation context reset
+  (V8) or pooled VM checkout (QuickJS) is sub-millisecond.
+- `lib/capybara/simulated/driver.rb` — Capybara `Driver::Base`
+  surface (visit / find / execute_script / window handling / modal /
+  tracing API).
+- `lib/capybara/simulated/node.rb` — `Driver::Node` over a
+  `(handle_id, context_gen)` pair so a handle from a pre-rebuild
+  Context can't ghost into the next one.
+
+## ES modules + importmap
+
+`<script type="module">` and `<script type="importmap">` work the
+same way they do in a real browser: bare specifiers resolve through
+the importmap, relative paths resolve against the importer's URL,
+and every load (including dynamic `import(...)`) routes back through
+the in-process Rack app. No bundling step, no Node toolchain.
+
+The standard importmap-rails layout works as-is:
+
+```erb
+<%= javascript_importmap_tags %>
+<!-- emits:
+  <script type="importmap">{ "imports": { "application": "/assets/application-...js", ... } }</script>
+  <script type="module">import "application"</script>
+-->
+```
+
+## Hotwire (Stimulus + Turbo)
+
+Stimulus and Turbo work both via UMD (classic `<script src>`) and via
+the standard ESM bundles imported through importmap. For
+importmap-rails apps, no changes are needed:
+
+```ruby
+# config/importmap.rb
+pin '@hotwired/stimulus'
+pin '@hotwired/turbo'
+```
+
+`window.fetch` routes through Rack, so Turbo's frame fetch and
+link-action POSTs round-trip the test app.
+
+## License
+
+[MIT](LICENSE).