Taroify: every component style is a second import, and the root manifest sits three releases behind

Component styles are a second import you have to write yourself

The shortest usage example in the documentation is two import lines, not one:

import { Button } from "@taroify/core"
import "@taroify/core/button/style"

export default function Index() {
  return <Button color="primary">开始使用 Taroify</Button>
}

The first line brings in the component, the second brings in its stylesheet, and the component does not pull the second one in. So a component that renders unstyled is the expected failure mode when the import is missing, and the size claim of under 1KB per component compressed only holds if you actually wire up the per-component imports rather than importing everything. That is also why on-demand import and tree shaking are recommended rather than optional: the package is built so that nothing is bundled unless you name it. The component itself takes styling props in the usual way, with a colour prop set to primary in the example.

The root manifest reports 1.0.3 and the tag list is already at 1.0.6

The repository root is a private manifest and its version number has fallen behind the published packages. `package.json` at the root reports `"version": "1.0.3"` and sets `"private": true`, so nothing at the root is ever published under that name. The release list shows three tags newer than it: v1.0.4 on 2026-08-04, v1.0.5 on 2026-08-09 and v1.0.6 on 2026-08-16. So the root number is a placeholder that tracks nothing, and the six workspace packages carry their own versions inside `packages/`. That is normal for a monorepo root and it is only worth stating because nothing in the documentation says so. A reader who clones the repository, opens the root manifest and concludes the library is at 1.0.3 will be three releases behind what npm serves.

Every version bump republishes all six packages

Three scripts drive the version bump, and all three carry the same two flags. `lerna:major` runs a major version with `--yes --no-git-tag-version --force-publish`, `lerna:minor` does the same for minor, and `lerna:patch` does it for patch. The `force-publish` flag is the one that matters. It tells the tool to bump and republish every package in the workspace whether or not that package changed, so a one-line fix inside the hooks package produces new versions of the core component library, the icon set, the commerce extensions, the CLI and the MCP server. The `no-git-tag-version` flag means none of the three creates a tag, so tagging is a separate manual step and the tag you see is not produced by the command that made the change. Publishing runs the full build first and then a script that walks the packages.

Node 22.12 to build, iOS 10 to run

The contributor requirement and the consumer requirement are separated by more than a decade. The root manifest requires `"node": ">=22.12.0"` and pins `"packageManager": "[email protected]"`, so anyone cloning the repository needs a very recent runtime and one specific package manager version, and the repository ships an `.nvmrc` to help. The published components make a much older promise: modern browsers, plus Chrome 51 or newer and iOS 10.0 or newer as the stated floor. Neither number is wrong. The build toolchain is where modern syntax and modern resolvers live, and a component library that claims iOS 10 support is making a deliberate choice about its audience. The practical consequence is that the floor in the browser support note tells you nothing about whether the project will build in your CI, and the engine field tells you nothing about what your users can run.

Two MCP surfaces ship, and one is described as merely existing

The monorepo publishes six packages, and the last two overlap. `@taroify/cli` is described as an offline component knowledge tool that covers a CLI, MCP and an Agent Skill. `@taroify/mcp` is described as the existing standalone MCP service. Reading those two descriptions together, the CLI is the current surface and the standalone package is kept for people already pointing at it, but the documentation does not say when one supersedes the other or whether the CLI calls into the standalone server. The repository layout supports the newer reading: there are `.agents/`, `.claude/` and a `skills-lock.json` at the root, which is the shape of a project that ships skills rather than just a server. Testing follows the same split. The `test:cli` script filters to the CLI package, runs its tests, builds it, and then runs a second suite named for the packed output.

The issue link points at a different GitHub organisation

The community section lists three ways to contribute and one of them points somewhere else. Pull requests go to `taroify/taroify`, discussions go to `taroify/taroify`, and the issue link goes to an account named `mallftaroifyoundry`. The manifest agrees with the first two rather than the third: the `bugs` field resolves to `taroify/taroify/issues/new`. So the one link a contributor is most likely to follow from a bug report is the one that leaves the project. The rest of the community block is consistent. The changelog is on the documentation site rather than in a changelog file at the root, and a group chat is offered behind a collapsed section with a note to identify yourself when adding the maintainer.

Three formatting and lint configs sit at the root, and one script uses one of them

The root listing carries a Prettier config with its own ignore file, a Biome config, and a Stylelint config with its own ignore file. Three tools for the same job, which is a choice rather than an accident, since Prettier handles general formatting, Biome handles linting and Stylelint is scoped to stylesheets. What the scripts show is that only one of the three is wired into the `lint` command, which runs a Biome check with a fix flag against the packages directory. Stylelint gets its own two scripts that target style files in both the packages and the site directory, but there is no script that runs Prettier. Formatting is therefore left to a tool the script layer does not invoke, which is the kind of arrangement that works until a contributor's editor and CI disagree. A `lefthook.yml` at the root and a sort script for package manifests sit alongside this.

Editorial conclusion

Taroify suits a team building a mini program or H5 app on Taro that wants Vant's visual language with React components and TypeScript types, and that is willing to own its style imports. It does not suit someone who expects a themed component library to work from a single import, because every stylesheet is a separate line and nothing is injected at runtime. Five things to check before you commit. Check how many of the six packages you actually need, since core, icons, hooks, commerce, cli and mcp install separately. Check whether your build already handles per-component style imports, because that is the pattern the usage example assumes. Check which Node version your CI has, since the repository requires 22.12.0 or newer and pins one package manager version. Check where you file an issue, because the community section links to a different GitHub organisation than the one hosting the code. And check whether the CLI or the standalone MCP package is the surface you want, since both are shipped. Licence is MIT, the newest release is v1.0.6 from 2026-08-16, and the default branch was pushed on 2026-10-01.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes