Skip to content
HARHAR

Eject

Most customization belongs in the customization contract: config, stages, hooks, plugins. But some teams genuinely want to own the runtime — audit it, patch it, pin it forever. har env eject makes that explicit instead of leaving a silently degraded fork.

Terminal window
har env eject

What it does:

  • Vendors the packaged runtime (the same bundle har itself runs) into .har/runtime/har.cjs.
  • Does not write wrapper scripts. Invocation is har env … or node .har/runtime/har.cjs env … (no har on PATH required).
  • Records the ejection in .har/manifest.json.

From that point the vendored runtime is user-owned: drift and har env maintain stop comparing it to upstream templates. har env doctor keeps validating the contract (env schema, stage registry, slot registry) and reports the ejected runtime as user-owned rather than flagging it as damage.

Trade-offs

Section titled “Trade-offs”

You take over upgrades: an ejected harness no longer picks up runtime fixes from newer @osfactory/har releases until you re-eject or adopt. Config, stages, hooks, and plugins keep working as before — the contract is the same.

Reversing it

Section titled “Reversing it”
Terminal window
har env adopt

removes .har/runtime/ (as does har env init --force) and returns you to the packaged runtime. Nothing about your config surface is touched.

When to eject

Section titled “When to eject”
  • Air-gapped or vendor-review environments that must not fetch from npm.
  • Teams that need to patch runtime behavior HAR does not expose yet — consider filing an issue too; hooks or plugins may already cover the need.
  • During 0.x → 1.0 migration, when a heavily customized harness is not worth lifting into the contract yet.