mirror of
https://github.com/hanzo-js/hanzo.git
synced 2026-10-30 18:55:09 +00:00
zeekay
d2ebbea5e3
hanzo already composed the cloud client and the AI library; the components
were the one part of the stack you still had to know a second package name to
reach. Now `import { Button } from 'hanzo/ui'` works the way `hanzo/ai`
already did.
Nothing is vendored. Each subpath is one re-export line, and a subpath is only
evaluated when it is imported, so reaching for the components does not pull
the cloud client and reaching for the client does not pull React.
hanzo
One install. The CLI, and the client.
npm install -g hanzo # the CLI
npm install hanzo # the client
import { Configuration, AdminApi } from 'hanzo' // the Open AI Cloud
import { Agent } from 'hanzo/ai' // agents and inference
import { Button } from 'hanzo/ui' // the component library
hanzo --version
What it is
A front door, and nothing else. The code lives where it is generated and maintained, and this package composes it:
| import | comes from | what it is |
|---|---|---|
hanzo |
hanzoai |
the full Open AI Cloud client, generated from the document hanzo-inc/cloud emits |
hanzo/ai |
@hanzo/ai |
the AI and agents library |
hanzo/ui |
@hanzo/ui |
the component library |
hanzo (the command) |
@hanzo/cli |
the Rust CLI, fetched for your platform on install |
Nothing is vendored and nothing is reimplemented here — there is one downloader, one generated client and one agents library, each in the package that owns it. Depending on any of them directly still works; this is the name you reach for when you do not want to choose.
Why one package
Four names published the same idea and a reader had to know which. The cost was not tidiness: a wrong guess installs a client that does not carry the surface you are calling. One name, two imports, one command.