wxmp is a Markdown editor aimed at one publishing target: WeChat official accounts

A tool for one publishing target, described in one sentence

The repository description says it all in Chinese: a WeChat official account article Markdown editor, using Markdown syntax to create a beautifully laid out WeChat graphic post. The project homepage is jaywcjlove.github.io/wxmp, the primary language is TypeScript, and the licence is MIT.

That framing is the whole product. There are no other targets. A general Markdown editor aimed at WeChat would be a preview pane; this is an editor whose output shape is a WeChat official account article, with the platform's inline styling constraints baked into the pipeline.

WeChat official accounts are a publishing channel where authors write inside the platform's own editor, and that editor is not a pleasant place to write long-form technical posts. A Markdown-based tool aimed at that audience is doing a specific job: keep the writing surface as plain text, and move the formatting burden into the conversion step.

The project has been through a few releases, with v2.3.3 from 2022-09-17, v2.4.0 from 2024-08-04 and v2.4.1 from 2025-05-27. The last push to the repository was on 2026-04-21.

The README itself is mostly something else. Before the project heading there is a long sponsorship section: a list of the author's other macOS applications with links to a download service, and a line inviting readers to support the work through those apps. The editorial content of the README comes after that, and it is short.

So the first thing an evaluator will notice is how little the documentation says. That is worth being honest about in this article rather than papering over with inference about what the code probably does.

A lerna monorepo with a website and a desktop app

The repository layout is the best evidence for how the project is put together, because the README does not describe the architecture. There is an electron/ directory, a website/ directory, a lerna.json, a package.json, a renovate.json, a .husky/ directory, a .prettierrc and a .prettierignore, and a LICENSE.

The package.json confirms the shape. It is private, it declares workspaces for electron/** and website, and it pins Node at 16 or newer.

The scripts show the two halves working separately.

  "scripts": {
    "build": "lerna exec --scope @wcj/* --ignore wxmp -- npm run build",
    "doc": "npm run-script build --workspace website",
    "start": "npm run-script start --workspace website",
    "build:app": "npm run-script build --workspace wxmp",
    "version": "lerna version --exact --force-publish --no-push --no-git-tag-version",
    "prepare": "husky install",
    "prettier": "prettier --write '**/*.{js,jsx,tsx,ts,less,md,json}'",
    "hoist": "lerna bootstrap --hoist",
    "clean": "lerna clean --yes"
  },

Read that carefully and the structure is clear. The website workspace is the browser front end, with its own build and start commands. The build script for the repository runs the build in every @wcj/* package but explicitly ignores wxmp, and a separate build:app script builds the wxmp package on its own.

That separation tells you the desktop application is published as its own package and built on its own schedule, while the shared packages under @wcj/* are built together.

The dev dependencies confirm the toolchain: lerna at 8, husky at 8, prettier at 3, React and React DOM at 18.2, tsbb for the package builds, cross-env for environment handling, and @lerna/legacy-package-management, which is the compatibility shim for lerna 8.

The version script uses lerna version with --exact and --force-publish, and both --no-push and --no-git-tag-version, so the release is driven locally rather than by CI tagging.

What the README does not tell you about the editor itself

It is worth listing the gaps explicitly, because an evaluator will otherwise assume the documentation is merely elsewhere rather than absent.

The README does not describe how the Markdown is converted into WeChat-compatible markup, which is the central mechanism of the project. It does not list the supported Markdown extensions, the themes, the code highlighting, the image handling or the typography presets. It does not say whether the conversion happens in the browser or in the Electron main process. It does not document a clipboard format, a drag-and-drop export, or how a finished article gets back into the WeChat editor, which is the step a user would actually care about.

It also does not mention the Electron packaging story: no installer names, no supported operating systems, no code signing or auto-update notes. The homepage is a hosted editor, and the existence of the electron/ workspace implies a desktop build exists, but the README does not point at a download for it.

What the README does establish is the project's existence, its licence, its release history and the general shape of the codebase. Everything else is in the source.

There is one piece of visible structure worth noting. The topics are markdown, markdown-editor, web-app and weixin, and the word web-app among them matches the fact that the front end is a website workspace rather than only a desktop shell. The hosted version is a web application first, and the Electron package is the wrapper around it.

So for a reader deciding whether to try it, the practical route is the hosted editor, and the practical route for understanding it is the package.json and the electron/ directory.

Running it locally, and the tooling the scripts expect

The README does not give an installation walkthrough, so this is the part where you read the scripts rather than the documentation.

For the browser front end, the start script delegates to the website workspace.

    "start": "npm run-script start --workspace website",

For the desktop application, there is a separate build target.

    "build:app": "npm run-script build --workspace wxmp",

The workspaces field in package.json is what makes those workspace flags work.

  "workspaces": {
    "packages": [
      "electron/**",
      "website"
    ]
  },

The hoist and clean commands are the older lerna workflows kept for compatibility, with lerna bootstrap --hoist and lerna clean --yes. The prettier script formats every JavaScript, TypeScript, Less, Markdown and JSON file in the tree, and the prepare hook runs husky install, so the git hooks are set up by the install rather than by a manual step.

The renovate.json at the top level means dependency updates are automated, which is a small maintenance fact that says something about how the author keeps the tree current.

One practical caution for anyone building this: the repository pins Node 16 or newer in the engines field while the dev dependencies are older generation packages, lerna 8 and React 18.2. A modern Node on a modern operating system is the environment the author is most likely to have used, but the pin is the documented floor, not a tested ceiling.

Where wxmp is the wrong tool

Three cases, and the first is about publishing scope.

If you publish to more than WeChat official accounts, this is a tool with a single output target. Writing the article in Markdown is the easy part, and the value is entirely in the conversion to the format the WeChat editor accepts. That conversion is the project, and it is not abstracted into a plugin architecture that the README describes.

The second is if you need a supported, documented product. The README is thin, the releases are infrequent, with a gap from 2022 to 2024 and then to 2025-05-27, and the last push was on 2026-04-21. This is a personal project with an unusual amount of history for its size and a documentation set that assumes you can read the source. That is a perfectly reasonable thing to adopt and a poor thing to build a team workflow on.

The third is if you are somewhere the hosted editor does not reach. A browser-based editor for a Chinese publishing platform has practical implications around network access and account availability, and the Electron build is the fallback for people who want it local. If neither works for you, the project cannot help.

One more practical caveat about the conversion itself. WeChat official account articles are rendered in a controlled environment with its own style restrictions, and any tool that produces a decorated post for that platform has to work within them. The README does not list which formatting features are supported or which are stripped on import, so an author who relies on a particular element will find out by trying it rather than by reading.

Licence, release mechanics and the state of the tree

The licence is MIT, recorded in package.json as well as in the LICENSE file, so there is no obstacle to forking the project or using the conversion logic in your own pipeline.

The release mechanics are visible in the version script, and they are worth reading because they say something about the project's workflow. lerna version is called with --exact and --force-publish, and with both --no-push and --no-git-tag-version. That means the version bump and the publish are performed locally, and the git tag is not created automatically, so the maintainer controls when the tag appears.

The repository also has renovate.json for dependency updates and .husky/ with a prepare hook for the git hooks, plus .prettierrc and .prettierignore for formatting. That is a small but coherent maintenance setup: formatting enforced, hooks installed automatically, dependencies updated by a bot.

For the licence position itself, there is nothing to untangle. MIT is permissive, the project is a tool rather than a component, and there are no runtime dependencies to worry about when you embed it.

What is left to verify is the practical question. The hosted editor is the fastest way to see whether the conversion produces output you would publish, and if it does, the local build with the website workspace gives you the same thing to hack on. Which one you should pick depends on whether you need to modify the conversion, and only the local tree lets you do that.

Editorial conclusion

Adopt wxmp if you publish to WeChat official accounts and want to write in Markdown rather than in the official editor's own format, and you are comfortable reading the source for the parts the README does not cover. Do not adopt it if you need a documented plugin API, since the README does not describe one, and treat the version gap as a risk, with the newest tag at v2.4.1 from 2025-05-27 and the last push on 2026-04-21. Verify first whether the hosted editor at the project homepage is enough for you, because that avoids installing the desktop shell entirely.

Frequently asked questions

Official sources

1. jaywcjlove/wxmp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases