# lanzouyun-disk: an Electron client for Lanzou cloud, split into a renderer and an app package > lanzouyun-disk is a desktop client for the Lanzou cloud disk service, MIT licensed and built on Electron with a MobX store. Its interesting structure is a two-package layout where the renderer builds with craco and the main process is compiled separately by tsc. **chenhb23/lanzouyun-disk** — 蓝奏云网盘、客户端，实现了蓝奏云大部分功能并添加了许多增强型功能，可作为网盘的日常管理工具使用。项目用 electron 构建，支持 macos 和 windows。 - Repository: https://github.com/chenhb23/lanzouyun-disk - Stars: 1,886 · Forks: 201 - Language: TypeScript - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/chenhb23-lanzouyun-disk ## What the client does with a Lanzou account lanzouyun-disk is a desktop client for the Lanzou cloud disk service, and the project's own description says it implements most of Lanzou's functionality and adds a number of enhancements. The stated aim is to work as a daily management tool for the cloud disk rather than as a thin browser wrapper. The platform support is stated in the README as Windows, macOS-x64 and macOS-arm64, with dark mode. Both Apple silicon and Intel are covered, which matters because the Electron runtime is duplicated per architecture. The primary feature list covers folders and files of any format for upload, resumable upload and download, file splitting and merging, a recycle bin, link parsing, and syncing of network resources or Lanzou resources. On top of that sit two layers of operations. Single-item operations work on files and folders and include multi-select, rename, share, sort and find within the current page. Batch operations also work on files and folders: batch upload with drag and drop, batch download, batch move, batch delete, batch share and batch setting a password. The batch password setting is the entry most specific to this service. Sharing with a password is a Lanzou concept, and being able to set it across a selection in one action is the kind of thing a web interface makes tedious. Whether it is worth moving to a desktop client depends entirely on whether you have enough files there for that tedium to matter. ## Two packages in one repository: craco for the renderer, tsc for Electron The build layout is the most reusable thing in this repository for anyone doing Electron with TypeScript. There is one root package.json plus an `app/` directory that carries its own package.json, and the scripts make the split explicit. The dev loop starts the renderer and the main process together, waiting for one before the other: ```bash yarn start ``` That resolves to `concurrently` running `cross-env BROWSER=none yarn react-start` and a second job that waits on `http://localhost:3000` before running `yarn electron-start`. The renderer is a Create React App project driven by craco, and the `BROWSER=none` guard stops CRA from opening a browser you do not want. The main process is compiled separately and run from the `app/` directory: ```bash yarn tsc-electron-build yarn electron-start yarn electron-debug yarn electron-build ``` Each of the electron scripts first runs `tsc -p tsconfig.electron.json`, then changes into `app/` and runs yarn there. TypeScript configuration is split to match, with `tsconfig.electron.json` for the main process, `tsconfig.base.json` for shared settings and `tsconfig.json` for the renderer. Production is two steps, `yarn react-build` then `yarn electron-build`, and release adds electron-builder with `--publish=always`. The `main` field points at `build/main/index.js`, so the renderer compiles into a `build/` directory that the packaged app loads. `yarn eject` exposes the CRA configuration if you need to, which is the standard escape hatch for a craco-based project. ## State in MobX, persisted, with a throttle and a debounce The state stack is mobx, mobx-react and mobx-persist, with React 18 and antd 5.19.3 for the interface and Tailwind configured at the root through tailwind.config.js. mobx-persist means the store survives restarts, which for a file manager client is the difference between a usable tool and a browser tab. Two lodash utilities are direct dependencies, and they hint at what the app does while you are not looking at it. `lodash.throttle` is what you would use to keep a UI from hammering the Lanzou API while you drag-select across a large directory, and `lodash.debounce` is what you would use for a search or filter box. Both are listed at versions `^4.1.1` and `^4.0.8`. The networking stack is more interesting. `got` at `^12.6.1` for HTTP, `cheerio` for parsing HTML, `tough-cookie` for a cookie jar, `form-data-encoder` and `formdata-node` for multipart bodies. The presence of cheerio alongside tough-cookie is the clearest signal about how this client works: a substantial part of talking to Lanzou is parsing HTML responses and carrying session cookies, rather than calling a documented JSON API. That is why the link parsing feature exists, and it is also the project's main fragility, which the article on release cadence comes back to. Other dependencies are ordinary desktop concerns. `@electron/remote` at `^2.1.2` gives the renderer access to main process modules. `electron-updater` handles updates, `electron-is` detects the platform, `fs-extra` handles files, `semver` compares versions, and `darkreader` at `^4.9.87` implements the dark mode that is also listed as a product feature. ## Quality gates exist, and husky runs lint-staged The repository is configured like a project that expects contributors rather than a personal script. There is a `.eslintrc.js` with a matching `.eslintignore`, `.prettierrc`, `.editorconfig`, and a `.husky/` directory with a pre-commit hook wired to lint-staged. The lint-staged configuration runs prettier in write mode over `src/**/*.{ts,tsx,js,jsx}` files, and the lint-staged configuration continues with further entries after the prettier pass. In package.json the husky block repeats the pre-commit hook definition, and there is a `prepare` script running husky, which means the hooks install themselves when dependencies are installed. That is convenient for contributors and slightly surprising if you clone the repository and do not want a git hook, though `HUSKY=0` is the usual escape. The test script is `craco test`, which is Create React App's Jest runner, so renderer tests run through the same tool that starts the dev server. There is no separate main-process test command in the scripts block, and no end-to-end harness listed. For a client whose job is manipulating files against a remote service, that is a reasonable place for coverage to be thin, and it is a fair question for anyone depending on the transfer logic. The postinstall hook is worth noting too: `electron-builder install-app-deps` followed by a yarn install inside `app/`. Native modules for the main process are rebuilt on install rather than at first launch, which is the arrangement that keeps packaging reproducible. ## Where the builds are, and the version gap The README includes a GitHub Releases badge, but its download instructions point to a Lanzou URL. It points at a Lanzou download URL with a password: `https://wwn.lanzouf.com/b01tpefuf` with password `4hol`. For a cloud disk client distributed through that same cloud disk, there is an obvious circularity, and it means you cannot verify a build's provenance from the repository. The version story is the part that needs attention before you install anything. Tagged GitHub releases exist for v3.4.11 on 2024-06-15, v3.5.2 on 2024-07-16 and v3.5.3 on 2024-07-17. The last push to the repository was on 2026-05-21. And package.json on the main branch reads version 4.0.0. So the default branch carries a version that has never been tagged, while the newest tag is more than two years older than that commit. That gap is the single most important fact in this project for an adopter. The feature list in the README describes the project as its source stands, but the README does not say which of those features are in the artefact you download. Version 4.0.0 exists in source form and possibly nowhere else. The repository is not archived, and a push dated 2026-05-21 is not nothing. But this is not a project where you can assume the published binary matches the source you are reading. ## What it replaces, and what it cannot do The alternative is the Lanzou web interface in a browser, and the difference in approach is real but narrow. This client is a separate implementation that has to keep up with whatever the service does, and the cheerio-plus-cookie-jar dependency list is the visible consequence of that relationship. The gain is desktop behaviour: multi-select across a directory, drag and drop upload, batch move, batch delete, batch share, batch password setting, find within the current page, sorting, a recycle bin, and resumable transfers. The costs are equally concrete. There is no Linux build, so if your desktop is Linux this is the wrong tool and no amount of configuration changes that. There is no API surface to script against: the operations live in the UI, batch selection is interactive, and nothing in the repository exposes a command line or an HTTP endpoint. A team that wanted to drive file operations from a script has nothing here. And the transfer code is tied to HTML parsing of a service the client does not control. That is a maintenance liability that no amount of TypeScript quality removes. The disclaimer in the README also asks users to understand and bear the risks before using the software, which given the dependency is not a formality. ## Conclusion Adopt lanzouyun-disk if you already keep data in Lanzou and want a real file manager experience on Windows or macOS instead of the web interface, because the batch operations, resumable transfers and recycle bin are the substance of the project. Do not adopt it if you need Linux, if you need the transfer code to survive a redesign of the Lanzou service, or if you need a maintained release, since the last tagged release is v3.5.3 from 2024-07-17 while the last push was on 2026-05-21 and package.json already reads 4.0.0. Verify first which artefact you are actually installing, because the README distributes builds from a Lanzou download link rather than from GitHub releases, and check the version number before relying on any of the listed features. ## FAQ ### Which platforms does lanzouyun-disk support? The README states dark mode support on Windows, macOS-x64 and macOS-arm64. There is no Linux build listed. ### Where do I download lanzouyun-disk? The README points at a Lanzou URL, `https://wwn.lanzouf.com/b01tpefuf`, with the password `4hol`, rather than at GitHub releases. The repository has tags up to v3.5.3 from 2024-07-17 while package.json on main reads 4.0.0. ### How do I run lanzouyun-disk in development? Run `yarn start`. It launches the craco-based React renderer with `BROWSER=none` and, once `http://localhost:3000` responds, runs `yarn electron-start`, which compiles the main process with `tsc -p tsconfig.electron.json` first. ### Does lanzouyun-disk support batch operations? Yes, on both files and folders: batch upload with drag and drop, batch download, batch move, batch delete, batch share and batch setting a password. Single-item operations include multi-select, edit, share, sort and find within the current page. ### What licence is lanzouyun-disk under? MIT, in the LICENSE file at the repository root. The README disclaimer states the project is free and open source, intended both for managing cloud disk files and for learning Electron desktop application development, and that users should comply with applicable law. ## Sources - [chenhb23/lanzouyun-disk on GitHub](https://github.com/chenhb23/lanzouyun-disk) - [Issues](https://github.com/chenhb23/lanzouyun-disk/issues) - [License: MIT](https://github.com/chenhb23/lanzouyun-disk/blob/main/LICENSE) - [README](https://github.com/chenhb23/lanzouyun-disk/blob/main/README.md) - [Releases](https://github.com/chenhb23/lanzouyun-disk/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chenhb23-lanzouyun-disk