v0.2.1

Generate the config from a stub

The file this package writes lived as a template literal inside its own
TypeScript — every backtick and every ${ escaped, and no way for an
application to change it without forking the package.

It is a stub now, read through codemods.makeUsingStub, the same route
ream-cli has always used for the make: generators. An application that
publishes stubs/<path> gets its copy instead, and the generated file is
byte-identical to what the literal produced.

The ream peer moves to ^0.2.26: that is the release the codemod appears in.

release: nebula 0.2.1

Mint ids from aurora's counter, not a second one

lib/id.ts had its own module-level counter. Aurora resets its sequence at the
start of each render pass — renderPage on the server, hydrate in the
browser — and a second counter living here saw none of those resets.

So a long-lived server shipped tooltip-trigger-14 while the browser,
hydrating from zero, minted tooltip-trigger-1 and looked it up. byId
answered null, floatingSurface had no anchor and returned before it opened
anything — on a page where the mount hook HAD run and the trigger WAS wired,
which is what made it look like a lifecycle bug.

Every id nebula mints now comes from the counter aurora resets. The names are
re-exported, so nothing importing them changes.

The suites all rendered client-side, which is the path that works; the new one
does what a ream page does — server-render, then adopt — and covers a tooltip
on its own and one inside another component's children.

The aurora peer moves to ^0.1.47: uid / resetIds / byId appear there.

---

Changes since v0.2.0.