# wechat-web-devtools-linux: running WeChat's DevTools on Linux > wechat-web-devtools-linux is a build script and toolset that assembles WeChat's Windows DevTools into something that runs on a Linux desktop, with a Docker path, a native path, a Linux version of the command line tool, and a C++ reimplementation of the official compiler. The author is candid that the tests only cover the fix at hand and that the tool is not fully verified on every release. **msojocs/wechat-web-devtools-linux** — 适用于微信小程序的微信开发者工具 Linux移植版 - Repository: https://github.com/msojocs/wechat-web-devtools-linux - Website: https://www.jysafe.cn/ - Stars: 1,318 · Forks: 127 - Language: Shell - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/msojocs-wechat-web-devtools-linux ## A porting project, not a product This is the Linux version of the WeChat developer tools, and the project description is precise about what it is: a complete set of scripts and tools for setting up a usable WeChat developer tools on Linux, aimed at the GNOME desktop, and designed to keep updating. It is also explicitly derived work. The README says the project is modified from dragonation's wechat-devtools repository, and the last section of the document is a disclaimer saying that the copyright of WeChat DevTools belongs to Tencent, that this project exists for learning and exchange, and gives a contact address. That framing matters for what you are adopting. This is not a competing IDE. It is an assembly of the official Windows toolchain into a form that runs on a Linux desktop, which means the tool tracks an upstream product that Tencent ships on its own schedule. The README's own progress note says the current tool can build the latest 2.02.2608080 on Linux and supports CLI mode, and the badges pin the pieces it assembles: WeChat DevTools 2.02.2608080, Electron 36.6.0, Node 22.16.0, and a wx-compiler at 0.2.0. The default branch is called electron, which is a hint that the Linux port is built on Electron, and the release list is a mixture of versioned tags and a rolling continuous build. The repository was last pushed to on 2026-10-11, and the licence is MIT. ## Three ways to get it, and an honest warning about each The usage section offers three routes, and the caveats on each are as useful as the instructions. The first is an online install, and the README is specific that it currently supports one channel, the deepin application store. That is a narrow but real distribution, and it is a distribution mechanism that does not need a build. The second is downloading a prebuilt package from the releases page. There are two kinds of artefact there, the versioned releases and a continuous tag built from the latest commit on the master branch. The README recommends the continuous build when a release has problems, and explains the trade honestly: it fixes bugs promptly but may also bring new ones. The third is building it yourself, and that is where the interesting engineering is. The recommended method, called method 0 in the README, uses Docker. You install docker and docker-compose, clone the repository with its submodules, and run a build script. ```bash git clone --recurse-submodules https://github.com/msojocs/wechat-web-devtools-linux.git tools/build-with-docker.sh ``` The README says this method succeeds 99 percent of the time, and attributes the failures to unstable networks while noting that the build already tries to use mirror sources. After the build you can optionally install a desktop icon with a second script, and then start the tool either by clicking the icon or by running bin/wechat-devtools from a terminal. ## The native build path, and why node_modules are recompiled Method 1 avoids Docker and builds with the node, npm and npx already in your PATH, with Node.js 22 LTS recommended including npm and npx. Two details in that section are worth copying out, because they explain a lot of the build's behaviour. First, the build script does not download or create a node/ environment inside the project, and the npm build tools are installed by default into cache/npm/node_global. Second, the node.versions entry in conf/config.json only specifies the target ABI version for native modules and does not restrict the Node.js version of the build environment, while the release packages call Electron's built-in Node through bin/node. So there are three Node.js versions in play, and the config file only pins one of them. That is the kind of detail that saves an afternoon when a native module compiles but does not load. The native build also needs system packages for nodegit, listed as python2.7, python3.6 or newer, libkrb5-dev, gcc, openssl, libssh2-1-dev, g++, make and pkg-config, with a note that an old 7z may have problems during extraction and a pointer to the Dockerfile.electron in the docker directory. ```bash ./tools/setup-wechat-devtools.sh ./tools/install-desktop-icon-bash.sh ``` The list of differences from other Linux ports explains why the project exists at all, and the fourth item is the one that matters most in practice. During the build, node_modules is recompiled, so that the native modules run correctly on Linux. The project also fixes a segfault in NW.js related to the Menu, so the latest version starts properly, that fix credited to dragonation, and it supports resuming interrupted downloads and uses the Taobao npm mirror to speed things up. The last difference is the most interesting: pure Linux support, using a C++ implementation of the official compiler, in the separate wx-compiler project. ## The command line tool, and the experimental Skyline path There is a CLI component, and it sits in the bin directory as a wechat-devtools-cli script, which is described as the Linux version of the WeChat DevTools command line support, with the upstream WeChat CLI V2 documentation as the reference for how it works. That matters for automation, because a mini program build that has to be driven from a script on a Linux CI runner needs a command line path rather than a GUI. The FAQ also covers Skyline, which is marked as an experimental feature. The instructions are to start the server, wait a while, and then click compile, with a warning that it is experimental and that issues should be filed, and a link to a list of known issues. The server is distributed as a container image with a version tag. ```shell docker run -d \ --network host \ -e HOST_UID=$(id -u) \ -e HOST_GID=$(id -g) \ -v "/dev/shm:/dev/shm" \ --name wechat_devtools_server \ ghcr.io/msojocs/skyline-client-server:${version} ``` The command passes the host user id and group id as environment variables, which is the pattern for running a container that writes files as the calling user, and it mounts the shared memory directory, which is what a browser engine expects to find. For context on how mature the port is, the repository also carries a feature test record in docs/Features.MD, a FAQ in docs/FAQ.MD, a changelog, a contributing guide, an English README, and a set of screenshots going back to version 1.02.2001191. ## What the tests do and do not tell you There is a paragraph in the README about the test record that is more honest than most, and it should be read before you plan around this tool. The note says the tests only passed when a particular feature was being fixed, and that this does not mean the tool is normally usable for you, because the author does not have the energy to run a full test before every release. It then points anyone who cannot solve a problem to open an issue. That is a candid statement of what a community port can promise, and it changes how you should read the feature test record. The record is a list of what worked at the moment somebody fixed it, not a compatibility matrix, and the releases arrive as the upstream product ships, which the README shows with version tags such as v2.02.2608080-1 and v2.02.2608070-2 only a couple of weeks apart. The practical consequence is that you should treat a new release as a new thing to verify rather than as a patch to an existing setup. The build script is the part that is repeatable, the tool underneath it is not. The system requirements sit in the same spirit. The desktop has to be Linux based, GNOME is preferred, and other desktop environments may have problems because they are untested. The CI built packages need a glibc of at least 2.23 and a libstdc++ of at least 3.4.21, and the wine based variant, which is struck through in the README, needed wine and wine-binfmt with version 5.0 or newer recommended. ## Conclusion wechat-web-devtools-linux fits a developer building WeChat mini programs on a Linux machine, who wants the official IDE rather than a third party emulator, and who is prepared to deal with a build that tracks an upstream product that ships new versions every few weeks. It does not fit someone who wants a supported tool, since the whole project is a community port of software whose copyright belongs to Tencent, and it does not fit a non-Linux desktop. Verify three things before you rely on it: that the tag you download matches the mini program SDK you are targeting, that your distribution has the glibc and libstdc++ versions the CI packages need, and that the compile step actually works on your machine, because the author's own note says the recorded tests only confirm a single fix at a time and do not mean the tool is fully usable. ## FAQ ### What does the wechat-web-devtools-linux project provide? A complete set of scripts and tools for building a usable WeChat developer tools on a Linux desktop, preferred on GNOME, that can be kept up to date. The current tool can build the latest 2.02.2608080 on Linux and supports CLI mode, and the project also ships a Linux version of the WeChat DevTools command line tool in the bin directory. ### How do I build the WeChat DevTools Linux port? The recommended method uses Docker: install docker and docker-compose, clone the repository with git clone --recurse-submodules, and run tools/build-with-docker.sh, followed by the optional ./tools/install-desktop-icon-node for the desktop icon. The native method instead uses the node, npm and npx in your PATH, with Node.js 22 LTS recommended, and runs ./tools/setup-wechat-devtools.sh. ### What are the system requirements for the Linux WeChat DevTools? A Linux desktop, with GNOME preferred because other desktop environments may have problems and are untested. The CI built packages require glibc 2.23 or newer and libstdc++ 3.4.21 or newer, and the native build needs the system packages for nodegit, including python2.7, python3.6 or newer, libkrb5-dev, gcc, openssl, libssh2-1-dev, g++, make and pkg-config. ### What is the wx-compiler project used for? The README lists pure Linux support among the differences from other ports, using a C++ implementation of the official compiler, which lives in the separate msojocs/wx-compiler repository and is pinned at version 0.2.0 in the badges. The project also recompiles node_modules during the build so native modules run correctly on Linux, and fixes an NW.js Menu segfault that stopped the newest version from starting. ### Is the WeChat DevTools Linux port reliable? The README says the recorded feature tests only passed when a specific feature was being fixed, that this does not mean the tool is normally usable, and that the author does not have the energy to test before every release. The current build can produce the latest 2.02.2608080, and problems are handled through GitHub issues. ## Sources - [License: MIT](https://github.com/msojocs/wechat-web-devtools-linux/blob/electron/LICENSE) - [msojocs/wechat-web-devtools-linux on GitHub](https://github.com/msojocs/wechat-web-devtools-linux) - [Project website](https://www.jysafe.cn/) - [README](https://github.com/msojocs/wechat-web-devtools-linux/blob/electron/README.md) - [Releases](https://github.com/msojocs/wechat-web-devtools-linux/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/msojocs-wechat-web-devtools-linux