Taro's preinstall hook rejects npm, and five of its six listed UI libraries still target Taro 3

The preinstall hook makes npm install fail before it starts

The root manifest pins the package manager and then enforces it at install time:

"preinstall": "npx only-allow pnpm",
"prepare": "husky install",
"build": "pnpm -r --aggregate-output --filter=./packages/* prod",
"lint": "eslint ./packages/ --ext .js,.jsx,.ts,.tsx,.mjs,.mts"

The `packageManager` field names pnpm 10.0.0, and `preinstall` runs a check that aborts the install under any other manager. So what this cannot do is let someone clone the repository and type `npm install`, which is the reflex for most JavaScript projects. The `prepare` hook then installs husky, so a clone without the git hooks directory in place will also behave oddly. The root package is marked `private`, which means it is never published itself; the publishable artifacts live under `packages/` and `npm/`, and the release script filters across those plus the native binding crate. One more detail worth knowing: the repository license field resolves to unknown, while this manifest and the README both say MIT, with copyright held by O2Team.

The root scripts lint the TypeScript packages and never touch the Rust crates

Taro is a polyglot repository. Alongside `packages/` there is a `crates/` directory, a `Cargo.toml`, a `Cargo.lock`, and a `rustfmt.toml`, so a Rust toolchain is part of the build. The root scripts reflect that asymmetry. The eslint invocation is scoped to `./packages/` with an explicit extension list, and `lint:style` runs stylelint over css and scss inside the same directory. The only Rust-aware script is `format::rs`, which runs `cargo fmt --all`. There is no equivalent script that runs clippy, and `tests/` sits outside the eslint path. So what a root-level command cannot do is tell you the Rust half is clean, only that it is formatted. The consequence is that a change to a crate can pass every script in the root manifest and still be rejected in review for something no automated check would have caught.

Five of the six listed component libraries declare support for Taro 3 only

The README publishes a table of UI libraries with a column for supported Taro versions, and that column is the useful part. taro-ui lists Taro 1, 2, and 3. NutUI, which is a Vue 3 library, lists Taro 3. taroify, described as a Taro version of Vant, lists Taro 3. The vantui fork built on VantWeapp lists Taro 3. Tard lists Taro 3. Only duxui lists Taro 4, and it is also the entry that mentions React Native, HarmonyOS, and H5 together. The current release line is 4.x, with 4.3.0 as the newest tag. So what a reader cannot infer from the library descriptions alone is whether a component set works on the major they would install, because four of the entries simply do not mention 4. The consequence is that choosing a component library means reading the version column first, and picking by popularity alone can land you on a library maintained for an older major.

Link time optimization is switched off in the release profile, with the reason inline

The Rust workspace config is short and its reasoning is recorded next to the settings. The release profile sets `codegen-units = 1`, `opt-level = 3`, `strip = true`, and `debug = false`, then turns off link time optimization with `lto = false` and an inline comment explaining that it is disabled by now because it significantly increases compile time, with a link to the relevant swc issue. The dev profile is the mirror image, with `debug = 2` and `incremental = true`. So what the shipped binary cannot be is the most aggressively optimized artifact this toolchain could produce, and the choice is a deliberate trade of runtime performance for build time rather than an oversight. The consequence is visible to anyone building the native binding locally, since a full build is the common case in development and the slow path is the one that was kept.

The napi crates are pinned with exact versions while swc floats inside a minor range

The workspace dependency block mixes two pinning styles, and the difference matters when an upgrade is due. napi is pinned to `=2.14.1` with the `napi4` and `tokio_rt` features, napi-build to `=2.1.0`, napi-derive to `=2.14.4`, and napi-sys to `=2.3.0`, all with the equals sign that makes Cargo reject anything else. swc_core by contrast is given as `0.87.*` with the `ecma_plugin_transform` and `ecma_utils` features, so it floats within the 0.87 line. There is also a local override, with a patch section pointing `taro_init` at `crates/taro_init` instead of the registry. So what this cannot offer is a single command that moves the binding forward: a napi upgrade means editing four exact pins that have to stay mutually compatible, because the Node API layer and the derive macros come from separate crates. The consequence is that the native binding is the part of this repository with the most deliberate upgrade friction.

A new feature needs an RFC document before any code is written

The contribution section describes two different paths. Ordinary code contributions go through a contributing guide, linked from the README. An important feature goes somewhere else entirely: you are told to write an RFC document first and follow Taro's RFC mechanism, which lives in a separate repository at NervJS/taro-rfcs, and only after the community has discussed and refined it can code be submitted. So what a contributor cannot do is open a large feature pull request and negotiate the design in review comments. The consequence is a real latency cost paid up front, and it applies to exactly the changes a cross-platform framework most needs to discuss, since a design decision here affects every supported platform at once. Reporting problems runs through a different door again, an issue helper page, alongside a strong recommendation to read guides on asking good questions before filing anything.

The README has a project status section with nothing in it

The table of contents in the README lists twelve sections, and the fourth is project status. The heading is there and the body is empty. Nearby, the use cases section states that Taro is in production use and links a case collection hosted on GitHub Pages, with a call to submit more cases through an issue. Elsewhere the project points at milestones for the development plan, at the releases page for the changelog, and at an official WeChat group for discussion. So what this file cannot give you is a statement of which major versions are supported, for how long, or what the compatibility promise is between 3.x and 4.x. The consequence is that a reader has to assemble that picture from the release tags and the documentation site, and an organization writing a support policy around the framework has no single authoritative sentence to cite.

Editorial conclusion

Taro fits a team that already ships on more than one of the named platforms and wants a single component codebase, and that is prepared to work inside a component library ecosystem where version support is uneven. It does not fit a contributor expecting to open a large feature pull request directly, since the RFC mechanism is a gate, or a team that needs one component library covering the current major. Before starting, install pnpm rather than npm, read the component table to find a library that lists your Taro major, and check whether the Rust binding crates need a toolchain as well as Node.

Frequently asked questions

Official sources

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