Skip to content

Docs: say which package to install, and what each one buys - #4

Merged
softov merged 1 commit into
mainfrom
docs/kit-install
Aug 24, 2026
Merged

Docs: say which package to install, and what each one buys#4
softov merged 1 commit into
mainfrom
docs/kit-install

Conversation

@softov

@softov softov commented Aug 24, 2026

Copy link
Copy Markdown
Owner

Now that 0.1.0 is on npm, the docs had to answer a question they never did: which package do I install, and what does each one get me?

The README opened with an install line and an import, and left the reader to infer the rest — that @textui/kit alone is enough to get something on screen, that Panel and Table are a second install, that the catalog resolves by name and therefore has to be registered, and that the CLI needs no install at all.

README

A new Installing section, with both npm and pnpm forms on every line:

Want Install
Something on screen @textui/kit — runtime, terminal, render
Panel, Table, charts, forms + @textui/widgets, registered via onBoot
Project setup, copied components npx @textui/cli init — no install
Runtime without a terminal @textui/core + @textui/terminal

The opening example now shows a complete working app — Box, Text, useState, useInput, render — all from @textui/kit, rather than a fragment referencing an undefined Dashboard.

I checked the split empirically against the published packages rather than assuming: @textui/kit and @textui/widgets have zero overlapping exports. Box/Text/hooks/render are kit; Panel/Table/Row/Column/registerBuiltins are widgets.

Getting started

Leads with @textui/kit instead of pnpm add @textui/core @textui/terminal. Those move down to The pieces underneath — which is what they are once the kit exists — and the hand-wired createApp hello goes with them. It was the first thing on the page and it is not the first thing to read.

Also notes the onBoot failure mode explicitly: forget it and nothing throws at compile time, because a missing registration is a runtime miss rendered visibly where the component should have been.

The snippets now cover kit

scripts/docs/snippets gained @textui/kit, so kit examples are typechecked like every other snippet. That immediately earned its keep — it caught a <Dashboard /> in my new prose that no snippet defined. 185 snippets check clean now.

The root README is not extracted for typechecking, so rather than leave a second hand-written variant to drift, its example is byte-identical to the verified one in getting started. I asserted that equality rather than eyeballing it.

Gate green: build, typecheck (all workspaces including snippets), docs:check, 185 snippets.

The README opened with an install line and an import and left the reader to
infer the rest: that `@textui/kit` alone is enough to get something on screen,
that `Panel` and `Table` are a second install, that the catalog is resolved by
name and so has to be registered, and that the CLI needs no install at all.
None of that was written down.

Both files now give npm and pnpm forms, and getting started leads with the kit
rather than with `@textui/core` and `@textui/terminal` - those move down to
"the pieces underneath", which is what they are once the kit exists. The
hand-wired `createApp` hello goes with them; it was the first thing on the page
and it is not the first thing to read.

The snippets package gains @textui/kit, so kit examples are typechecked like
the rest. That immediately caught a `<Dashboard />` in the new prose that no
snippet defined. The README is not extracted, so its example is byte-identical
to the one in getting started rather than a second version to drift.
@softov
softov merged commit ab4c5ba into main Aug 24, 2026
3 checks passed
@softov
softov deleted the docs/kit-install branch August 24, 2026 21:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant