# Ink: the readme documents a version npm has not published yet

> A React renderer for terminal apps that lays out with Yoga, depends on the React reconciler but not on React itself, and ships a build directory as its entire published package. The readme on master describes an upcoming version, the newest tag is two months older than the last commit, and the project rejects fully AI-generated pull requests by naming the models it will accept.

**vadimdemedes/ink** — 🌈 React for interactive command-line apps

- Repository: https://github.com/vadimdemedes/ink
- Website: https://term.ink
- Stars: 39,966 · Forks: 1,053
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/vadimdemedes-ink

## The readme is ahead of the registry, and says so in a note

There is a note directly under the install command, and it changes how the rest of the page should be read. It says the readme documents the upcoming version of Ink, and that for the latest stable release you should look at Ink on npm. So the documentation you are reading describes code that is not yet published. The timeline makes the gap concrete. The newest listed release is v7.1.1, dated 2026-07-16, after v7.1.0 on 2026-06-17 and v7.0.6 on 2026-06-12, while the last commit to the default branch is dated 2026-09-21. The manifest version is 7.1.1, matching the newest tag rather than the branch. The consequence is that anything you learn from the readme may describe a method that the installed package does not have, and the two-month stretch between the last tag and the last commit means the branch is well ahead of what you can install. Pin a version and read the notes for that version rather than trusting the page you found through a search result.

## The reconciler is bundled and React is not

The install line names two packages.

```sh
npm install ink react
```

That is not redundant. Look at the dependency list and `react-reconciler` is there at a pinned major, but React itself is not. So Ink depends directly on a specific range of the React reconciler, which is the machinery that turns component output into host operations, while the React you actually render with is whatever version you chose to install. The result is an unusual version-coupling shape. Ink's internals are tied to one reconciler line, and your rendering library is decoupled from it and from Ink. Two practical consequences follow. There is no bundled React to fall back on, so a version mismatch surfaces as a runtime failure rather than a missing dependency. And because the two versions are chosen separately, the combination you test is a combination you have chosen, not one Ink validated for you, which is worth knowing before you conclude a problem is Ink's fault.

## AI-generated pull requests are rejected, and the policy names two models

The contribution policy is the most specific paragraph in this readme, and it is not boilerplate. It states that fully AI-generated pull requests are not accepted, that you can use AI but the result should be verified and cleaned up by a human, and that only two models are accepted, Opus 4.6 at high effort and Codex 5.4 at extra high. It goes further and expresses a preference for how the two are combined, saying that a change should preferably be created with Opus and verified by Codex. That is unusual enough to be worth reading twice. It means the gate is not a general anti-automation stance but a specific, named condition, and it means a contribution drafted by an assistant and submitted as-is is rejected on the stated grounds rather than on quality. For anyone planning to send a patch through an agent, the practical reading is that the human verification step is the part being enforced, and the model list tells you which tools the maintainers consider acceptable for the draft. Nothing in this policy affects the library at runtime.

## Twenty-eight example directories, and the names show where the work is

The examples directory is the closest thing this project has to an API guide, because the readme states that only Ink's methods are documented there and that React's own documentation covers everything else. It holds twenty-eight directories, and reading their names is more informative than counting them. The component-shaped ones are what you would expect, `counter`, `static`, `table`, `select-input`, `chat`, `borders`, `justify-content`, `use-animation`, and `use-focus`. The rest describe the hard part of the project. There is `alternate-screen`, `cursor-ime`, `incremental-rendering`, `render-throttle`, `suspend-terminal`, `terminal-resize`, `subprocess-output`, `concurrent-suspense`, and `aria`. That inventory is the honest statement of where the difficulty sits. Ink's problems are not drawing boxes, which Yoga solves, but negotiating with a terminal that has a cursor, an alternate buffer, no layout engine, and an input method editor, while a React reconciler is driving all of it. Judge the library on those directories rather than on the component examples.

## Yoga gives you Flexbox, and the dependency list is all ANSI

The layout claim is specific. Ink uses Yoga to build Flexbox layouts in the terminal, so most CSS-like properties are available in it as well, and the page's framing is that if you already know React you already know Ink. The word carrying the weight is most. Yoga solves the box model, and the dependency list shows what the terminal half of the problem costs. There is a package for tokenizing ANSI, for escaping it, for applying styles, for boxes, for cursor control, for truncating a string to a cell width, for computing string width, for finding the widest line, for wrapping while counting ANSI codes, for indenting, for detecting CI, and for patching console output. Then `chalk` for colour and `terminal-size` for dimensions. So the Flexbox experience is real and the escape-sequence bookkeeping is delegated to two dozen small packages, which is the trade you are making. It also means Ink's rendering is sensitive to how wide a cell is, and the examples for borders and backgrounds are where the edge cases show up.

## The published package is one build directory, and a git install compiles

Look at what the manifest publishes. The `files` array contains a single entry, `build`. The `exports` map points types at `./build/index.d.ts` and the default at `./build/index.js`, and the package is ESM. So the registry tarball is compiled output with no source in it, and the examples directory, the recipes directory, and the benchmark directory are all things you can read on GitHub but will not find in `node_modules`. That matters when you want to know how something is implemented, because the answer is a link rather than a file. The second detail is the `prepare` script, which runs the build. That is the npm lifecycle hook that fires on install from a git reference, so a from-source install compiles the TypeScript on your machine rather than downloading a prebuilt artifact. The practical consequence is that installing from Git is slower and needs a working build toolchain, and the release is what you should install unless you have a reason not to.

## The test command forces colour on, because the assertions are escape sequences

The test script is one line and it explains the shape of the test suite.

```json
		"test": "npm run typecheck && npm run lint && FORCE_COLOR=true ava",
```

Three things happen in order: a typecheck with no emit, a lint pass, then the runner with `FORCE_COLOR=true` set in the environment. That last part is the interesting one. These are terminal tests, so the assertions are on rendered output, which is full of escape sequences, and forcing colour on makes that output identical on a developer's machine, in CI, and on a terminal that has colour disabled. Without it the same test would produce different bytes in different environments and the snapshots would be worthless. The development dependencies support the same idea, with fake timers for the interval-driven components in the examples and a faker for generating fixture data. The example and benchmark runners are configured the same way, using tsx to execute TypeScript directly with node warnings suppressed, which is why you can run any of the twenty-eight examples without a build step.

## Conclusion

Use Ink when you want React's component model and a real Flexbox layout in a terminal, and you already accept that terminal mechanics, alternate screen handling, cursor behaviour, and render throttling are problems you will solve yourself against the examples. Do not adopt it expecting the readme to match what npm serves you, because master documents an unreleased version. Before you start, check which version your readme is describing against the newest tag, install React explicitly rather than assuming it comes with Ink, and if you plan to send a pull request, read the contribution policy first, since it names specific accepted models and rejects unreviewed generated code.

## FAQ

### Is Ink a React renderer?

Yes. Ink states that since it is a React renderer, all features of React are supported, and it points to the React website for React documentation, noting that only Ink's own methods are documented in its readme. Its manifest carries react-reconciler as a runtime dependency.

### What is the React library, in relation to Ink?

React is not a dependency of Ink, which is why the install command is `npm install ink react` and you bring React yourself. Ink describes itself as providing the same component-based UI building experience React offers in the browser, but for command-line apps, using Yoga to build Flexbox layouts in the terminal.

### Is React a UI tool, and what does Ink add to it?

Ink's own framing is that it gives command-line apps the component-based experience React offers in the browser, with most CSS-like properties available because layout goes through Yoga. The readme does not describe React itself beyond deferring to the React website for React documentation.

## Sources

- [License: MIT](https://github.com/vadimdemedes/ink/blob/master/LICENSE)
- [Project website](https://term.ink)
- [README](https://github.com/vadimdemedes/ink/blob/master/README.md)
- [Releases](https://github.com/vadimdemedes/ink/releases)
- [vadimdemedes/ink on GitHub](https://github.com/vadimdemedes/ink)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vadimdemedes-ink