Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@amritk/create-mini-lynx@0.1.0

Minor Changes

• 8e575fd: Add create-mini-lynx: one command to a running app, in a browser or on a phone.

  bun create @amritk/mini-lynx my-app writes a complete @amritk/mini-lynx
  project, installs it, and leaves you one command from either loop:

  • bun run dev — the app in a device frame in a browser tab, on
    @amritk/mini-lynx-preview, with a size picker and no phone involved.
  • bun run dev:device — rspeedy dev through
    @amritk/mini-lynx-rsbuild-plugin: a real .lynx.bundle, two QR codes, and
    Lynx Explorer.

  One src/app.tsx feeds both; what differs is the entry — src/main-thread.ts
  for the device (plus src/background.ts, the chunk NativeModules lives in)
  and src/preview/main.ts for the browser. The DOM libs are withheld from
  everything outside src/preview/, in a second tsconfig pass rather than a
  comment, so a document in app code fails the type check instead of failing on
  the only target that ships.

@amritk/mini-lynx-preview@0.1.0

Minor Changes

• 8e575fd: Publish the browser preview engine as a package.

  Lynx's Element PAPI implemented over the DOM — createDomPapi,
  installLynxReset/LYNX_ROOT_ATTRIBUTE and createVisualViewportEmitter — so a
  @amritk/mini-lynx app runs in a browser tab with nothing about it changed. It
  was apps/playground-mini-lynx/src/lib/ until something outside this repo
  needed the same engine; the playground now boots on the package, so there is one
  implementation rather than two.

  It is the loop with no phone in it — @amritk/mini-lynx-rsbuild-plugin is the
  one with a phone, and a scaffolded app carries both.

  Every import of the runtime here is import type. A preview that called
  setEngine itself would call it on whichever copy of the runtime it resolved,
  which in a consumer's app can be a different copy from the one the app imported
  — and the symptom of that is a blank screen with no error in it. The four lines
  of wiring stay in the app.

@amritk/mini-lynx-rsbuild-plugin@0.2.0

Minor Changes

• d572153: Add @amritk/mini-lynx-rsbuild-plugin — the rspeedy build for a
  @amritk/mini-lynx app, so rspeedy dev → QR code → Lynx Explorer works on day
  one.

  A Lynx template is a container with two code slots — a main-thread chunk the
  engine executes to build the first screen and a background chunk it loads as
  /app-service.js — plus CSS the encoder compiles. rspeedy builds the container;
  which code goes in which slot is the framework's to say, and every framework
  says it in a plugin of its own. This is that plugin for a runtime that renders
  on the main thread and drives the Element PAPI itself: pluginMiniLynx() splits
  one entry into two chunks, adds the template plugin and encoder, sets the
  lynx:main-thread asset flag the encoder splits on, wraps the background chunk
  for the engine's module loader, and points the JSX transform at
  @amritk/mini-lynx.

  In dev it wires the dev-server client and a devtool reload. Nothing hot-updates
  and nothing should — a component runs once here — so an update no module accepts
  falls through to a page reload, which is safe because renderPage claims
  removeComponents.

  apps/starter-mini-lynx is a four-file app built through it, and
  docs/mini-lynx-explorer.md records the loop along with what has been verified
  (one real build per commit, whose main-thread chunk is executed against the fake
  Element PAPI and asserted on) and what a device still has to answer.

@amritk/starter-mini-lynx@0.0.1

Patch Changes

• Updated dependencies [d572153]
  • @amritk/mini-lynx-rsbuild-plugin@0.2.0