ZTools: a uTools style launcher where the settings panel is itself a plugin

The setting panel is itself a plugin, built by a separate pnpm run

Look at the dev script rather than the feature list. dev is not a single process; it is concurrently -n "main,setting" -c "blue,green" running two tasks, dev:main and dev:setting, and the second one simply changes directory into internal-plugins/setting and runs pnpm dev there. The build script mirrors that shape: pnpm build is pnpm typecheck && pnpm build:setting && electron-vite build, with build:setting again entering internal-plugins/setting to build it before the main bundle is produced. The consequence is that the settings UI is not part of the main Vue application. It is an internal plugin living inside the repository, which is also why the project's own plugin lifecycle has to work before any of your own plugins do. There is a kill script backed by pkill -9 Electron and a dev:clean that chains the two.

Type checking is split into two projects with separate configs

ZTools runs two type systems over one codebase. typecheck:node is tsc --noEmit against tsconfig.node.json covering the main process and preload, while typecheck:web is vue-tsc --noEmit against tsconfig.web.json covering the renderer, and typecheck runs them in that order with && so a main process type error stops the build. Both use --composite false, which disables incremental project references for these one-shot checks even though tsconfig.node.tsbuildinfo and tsconfig.web.tsbuildinfo are committed in the repository root. The three target configs, tsconfig.json, tsconfig.node.json and tsconfig.web.json, line up with the process boundary that Electron enforces anyway. Build verification is therefore not optional here: pnpm build begins by running the full typecheck, so a build failure can be a type failure rather than a bundling failure.

Target platform is passed through an environment variable, not a flag

Cross-compilation is handled by electron-builder flags plus a variable that changes what the source builds. build:mac is cross-env ZTOOLS_TARGET_PLATFORM=darwin pnpm build && electron-builder --mac --publish never, build:win is the same shape with win32 and --win, and --publish never is repeated on both so a local packaging run never pushes anything. The separate build:mac:x64 variant exists alongside a plain mac target, which tells you architecture is a parameter rather than an inference. Because the platform variable is injected into the inner build, the bundle step is not platform neutral: code paths can read ZTOOLS_TARGET_PLATFORM and drop or include platform specific modules, such as the region screenshot support the tech stack lists as Windows only.

Submodules and two sibling repositories sit inside the tree

Getting a working tree starts the ordinary way, with pnpm as the package manager rather than npm:

# Clone the repository
git clone https://github.com/ZToolsCenter/ZTools.git
cd ZTools

# Install dependencies
pnpm install

# Development mode
pnpm dev

# Build
pnpm build:mac    # macOS
pnpm build:win    # Windows
pnpm build:linux  # Linux (Default Arch)
pnpm build:linux:x64 # Linux (amd64/x64)
pnpm build:linux:arm64 # Linux (arm64)

Three entries at the top level are not application code. ztools-api-types and ztools-plugin-cli appear as directories beside src/, and .gitmodules is present, so the plugin type definitions and the plugin command line tool arrive as submodules. The project description states the rule for contributors plainly: fork the repository first, and if you need to contribute code, fork ztools-api-types and ztools-plugin-cli as well. That is an unusual amount of ceremony for a launcher, and it follows from the design. Plugin authors do not hand-write the API surface, they import types from one submodule and ship with a CLI from the other, so a change to the plugin contract has to land in two other repositories before the main app can use it. internal-plugins/ is a fourth place plugin-shaped code already lives, namely the settings panel.

Storage is LMDB, and plugin data is kept in separate stores

The database choice is LMDB, a high-performance embedded key-value store, and the migration to it is listed among the completed roadmap items. Alongside it sits search over Fuse.js with Pinyin support, which is what makes typing a pinyin fragment find a Chinese application name, plus regex matching and history tracking on the launcher side. Data isolation is the part that matters for plugin authors and is stated as a feature: each plugin gets independent plugin data storage rather than sharing one namespace with the host. The feature list also claims cross-platform native clipboard management with history, search and image support, implemented through the C++ Node-API modules rather than in JavaScript, alongside window management and the Windows region screenshot. A dev-app-update.yml file exists for update configuration.

Linux builds exist as scripts, Linux support does not

The build commands and the support matrix disagree, and the disagreement is the clearest signal of where this project stands. package.json exposes build:linux, build:linux:x64 and build:linux:arm64, and the source block lists build:linux as Linux Default Arch alongside explicit amd64 and arm64 variants. The feature list, however, states native support for macOS and Windows, the development requirements ask for a macOS or Windows development environment, and Linux support remains an unchecked item on the roadmap. So the scripts make it possible to produce an artifact, while nothing in the documentation claims that artifact is supported. Two other roadmap entries are also unchecked and worth noting before you design around them: plugin auto-update and an MCP toolkit. Cloud sync is marked optional rather than planned.

uTools is acknowledged as inspiration, not as a dependency

The positioning statement calls ZTools an open source implementation of uTools, and the acknowledgements name uTools as the source of inspiration. Nothing in the dependency list comes from uTools: the stack is Electron 41 with Node 24.15 and Chrome 146, Vue 3 with TypeScript, Vite and electron-vite, LMDB, Pinia and Fuse.js. So the relationship is a behavioural one. ZTools reproduces the launcher and plugin platform shape, with Quick Launch for pinyin search, regex matching, history and pinned apps, a plugin system split between UI plugins and headless plugins, clipboard history, six theme colors alongside system, light and dark modes, a plugin market for online installation and management, custom global shortcuts, and plugins that open in independent windows. The install artifact names echo the same lineage, with ztools as the macOS dmg and Windows setup filename stem.

Releases are frequent through v3.2.0, and the version lives in two places

The release history shows a project shipping quickly: v3.2.0 on 2026-08-29, preceded by v3.2.0-beta.4 on 2026-08-28 and v3.2.0-beta.3 on 2026-08-27, which is a two day window from beta to final. The last push to the default branch main is dated 2026-10-03. Against that cadence the version has two homes. package.json declares version 3.2.0, and it is the only place a version string is edited; the release tags are cut from it. That is worth noting because a launcher distributes by download, so the version a user sees, the artifact filename of the form ztools-x.x.x.dmg and the tag in the repository have to agree, and nothing in the scripts listed here enforces that. Prettier and ESLint are configured through .prettierrc.yaml, .prettierignore, eslint.config.mjs and .editorconfig, with hooks in .githooks/.

Editorial conclusion

Use ZTools if you want a uTools shaped launcher on macOS or Windows and are willing to work in an Electron and TypeScript codebase, since the plugin contract, the marketplace and the settings panel are all implemented and the release cadence is fast enough that features arrive without long waits. Do not plan on Linux, because Linux has packaging scripts but no support claim, and do not assume plugin auto-update or an MCP toolkit, since both are unchecked roadmap items. If you intend to contribute, budget for the submodule work: the plugin API types and the plugin CLI live in sibling repositories that the project asks you to fork first. Before you rely on it, verify three things yourself, that the plugin data isolation the feature list promises actually keeps plugin stores separate on your version, that the artifact you downloaded matches the tag you intend to upgrade to, and that any native module you need, region screenshot in particular, exists for your platform rather than only for Windows.

Frequently asked questions

Official sources

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