yuque-tools: exporting a Yuque knowledge base without an API token

Three distributions of the same idea

yuque-tools is described as a plain and unpretentious set of Yuque tools, and its distinguishing claim is in the parenthetical on the package description, a knowledge base and team resource bulk export and backup tool that needs no token. That last part is the whole design, and it explains the three distributions. The first is a standalone command line program with no environment requirement at all, downloaded and run, and the linked release page carries the title announcing version 1.0.0 of the executable with no Node environment needed. The second is the Node.js version of the command line tool, whose usage is documented directly in the repository under the packages directory for the CLI. The third is a graphical application, which the README redirects to a separate project rather than describing here. The point of the split is that the three serve different constraints, one for people who will not install Node, one for people who already have it and want the source, and one for people who want a window rather than a terminal. The browser extension is a fourth surface rather than a fifth distribution, and it appears in the repository topics and in the update record linked from the README.

What is actually covered, and where the coverage stops

The supported features list is the clearest statement of scope in the README, and it is worth reading as a coverage map rather than as a feature list. There is the personal knowledge base. There is the space knowledge base, which is the team level. There is the collaborative knowledge base. There is the short notes feature, and the README credits that to another developer, so it arrived as a contribution rather than as part of the original work. And there is team resource bulk export, which is marked in a colour as supported only by the executable version, with a download address and a link to the source. That last distinction is the practical constraint of the project and it is stated in the list rather than buried. If your need is a full export of a team's resources, the command line tool and the browser extension will not do it and you need the standalone binary. The list also mentions an easter egg, with a pointer to the source file where the usage is explained and a note that documentation is not written for it, which is a good example of a project treating its oddities as things to point at rather than hide.

The interactive list tells personal spaces apart from the rest

There is one behavioural detail in the README that says more about how the tool was built than any feature description, and it is a change in version 2.1.0. From that version, in the interactive list, a person prefix marks the personal knowledge base, and everything else is marked with a group prefix. That is a small interface decision with a large usability consequence, because the interactive list is where you choose what to export, and a list in which personal, team and collaborative documents appear with the same marker is a list you have to read carefully every time. Marking the personal space differently lets you pick the right scope at a glance. It is also the kind of detail that reveals the tool's origin, since it is the kind of change that comes from a user asking for it after being unable to tell the entries apart, and the README records the version boundary so you know when the behaviour changed under you. The interactive list itself is the core of the experience, since the tool is designed around browsing a knowledge base and choosing from it rather than around a command line with a long list of flags, which is also why the knowledge base is described as having a person prefix and everything else a group prefix.

A pnpm workspace with one root package

The repository is a pnpm workspace, and the root package.json is deliberately thin. It carries the name yuque-tools, a version of 1.0.0, is marked private, and its description names the tool set and the browser extension assistant role, and the author is vannvan. The only script is a TypeScript compile that delegates to the filtered package.

{
  "name": "yuque-tools",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "tsc": "pnpm --filter=yuque-tools run tsc"
  },
  "author": "vannvan",
  "license": "MIT",
  "devDependencies": {
    "pnpm": "^8.10.0"
  }
}

The description is in Chinese, which is a reasonable signal about who the tool is for, and the workspace file and lock file at the top level point to the packages directory holding the actual work, including the command line package with its own README and its own changelog, and the Chrome extension package with a changelog of its own. The separate changelogs matter more than they sound, because a tool that talks to somebody else's web application changes when that application changes, and a per-surface changelog is how you tell whether the extension or the CLI is behind. The only dev dependency is pnpm itself, which says the workspace is managed with the package manager rather than with a build tool, and there is a .npmrc at the root.

Where yuque-tools is the wrong tool

The first limit is the one the project itself is honest about, which is that the team resource bulk export only works in the standalone executable, so the choice of distribution is not a matter of taste but a requirement. The second is that the tool is tied to one service, and a knowledge base is only as portable as the export format, so the value of the tool is the archive, not the ongoing workflow, and anyone wanting live sync between a Yuque space and a local directory has a different problem. The third is the legal and terms of service dimension, which the tool addresses by not using an API token at all, since a browser session carries its own credentials and a token-based API would have a different agreement attached. That is a legitimate design for a personal backup tool and it is not a design to build a commercial product on without checking what the service permits, and the fact that the author states no money has been received or will be received, and that the tool is for exchange and sharing, is an indication of intent rather than a legal position. The fourth is the pace. The only tagged release in the list is v1.0.0-beta from 2023-09-30, while the last push to the repository was on 2026-09-26, so the visible artefacts are old and the changelogs inside the packages are where the current state is described. The fifth is the platform, since the graphical application and the standalone binary live in a separate Rust project rather than here, so this repository is the TypeScript half of a wider tool set, and reading only it will not tell you everything the project does.

Editorial conclusion

Adopt yuque-tools if you maintain a Yuque knowledge base and want a readable bulk export or a backup you control, and you are working in a way the tool supports, which for personal, team and collaborative spaces is the command line program. Skip it if you only need to read a couple of documents, since Yuque's own export covers that. Verify first which distribution you want, since the team resource batch export is only supported in the standalone executable and the command line and browser extension cover the knowledge base side, and read the tool's own terms of use for the service before you automate anything against it.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vannvan/yuque-tools on GitHub