WP-Desktop: a deployment-only repository for the WordPress.com desktop app

A repository with one file and a pointer to the real source

The repository root of Automattic/wp-desktop contains exactly one tracked file, README.md, and that file is the entirety of the project's own documentation. A note near the top states that the source code for the project is now maintained in the WP-Calypso repository, under its desktop directory, and that this repository is used for deployment purposes only. Issues are explicitly redirected to WP-Calypso rather than filed here. That is an unusual shape for a project that ships a widely used desktop application, and it changes what the repository is for. It is a release and packaging surface, not a development one. A developer looking for the Electron build scripts, the renderer code, the login flow or the test suite will not find them in this tree, and the version heading at the top of the README tracks the current application release rather than a library version.

The changelog is the only documentation this repository keeps

Everything else in the README is a list of changes, formatted as commit subject lines with pull request numbers. The entries for v8.2.4 describe a Linux packaging icon fix for electron-builder, restoring keyboard focus to the content view when the window is activated, registering the wpdesktop protocol handler in the Store appx manifest, a follow-up on an Azure signing review, a json bump in the bundler group, dropping the macOS code signing keychain workaround, removing the Windows PFX signing fallback, and a fix to the electron-builder 26 config schema. Below those sit dependency and infrastructure entries: a security update to desktop build dependencies, a brace-expansion bump, an excon bump for a Dependabot alert, a faraday bump, and the replacement of lodash debounce in the desktop app with a local helper. Reading the list top to bottom tells you that the release was mostly about signing, packaging and supply chain hygiene rather than visible features.

Code signing churn across three platforms

Three of the listed changes are about how the application binary is signed for distribution, and that concentration is unusual enough to notice. The macOS code signing keychain workaround was dropped, the Windows PFX signing fallback was removed, and there is a follow-up on an Azure signing review. Taken together they suggest the signing path was consolidated around a single mechanism rather than maintained as parallel fallbacks per platform, and the Azure reference points to the pipeline where the release is signed for Windows. A team that forks the desktop app inherits this pipeline, so the signing configuration matters more than it would in a typical application repository, where it is usually a solved problem in a CI config. The removal of the CircleCI Desktop pipeline in the same list is consistent with the release job living elsewhere now, in the deployment-only repository this README describes.

Beta channel naming and prerelease marking

Two small entries concern how the beta channel is labelled. One changes the suffix used for beta builds from -beta.1 to -beta1 for consistency, and another marks beta releases as prereleases. The second matters to anyone automating updates against the release feed, because a beta that appears as a stable-looking tag can be picked up by tooling that filters on prerelease status. The repository publishes v8.2.4 and v8.2.4-beta.1 alongside an earlier v8.2.3, and the beta entry for v8.2.4 predates the final by a day, which is the normal shape of a release candidate window. The naming change is a small compatibility detail, but it is exactly the kind of thing that breaks a script that parses tag names, and it is recorded in the README rather than in a release note.

End-to-end login tests stopped recording traffic

The E2E login test no longer generates or tracks HAR files, and the recordHar option survives only as a commented-out line in the same test. A HAR capture is an archive of the raw HTTP traffic of a session, and in a login flow it contains the very requests and responses that prove how the session is established. Removing it from the default test run reduces the amount of session material written to disk during continuous integration, which is a reasonable trade against the ability to replay and inspect the exact request sequence. The decision to keep the option in the file, commented rather than deleted, means it can be re-enabled by hand when someone does want the traffic captured for debugging. For anyone auditing how the desktop app authenticates, this repository tells you where to look, and the WP-Calypso tree is where the test and the login implementation live.

Dependency maintenance is done through the monorepo, not here

The remaining entries show how updates reach the desktop app. The security update to desktop build dependencies, the brace-expansion and faraday bumps in the bundler group, the excon bump for a Dependabot alert, and the json bump all appear as changes in the desktop subtree of the larger project. The lodash debounce replacement is the more interesting one, because it removes a dependency rather than updating it, replacing a lodash helper with a local one inside the app. That reduces the shipped surface of the desktop bundle, and it also means the change now lives in application code that the maintainers own rather than in an upstream library. Taken with the removal of the CircleCI pipeline, the picture is consistent: this repository records the tail end of a release process whose source of truth, and whose review process, sit in WP-Calypso.

Getting the app, and why there is no build command to copy

There is no clone, install or build step to reproduce from this repository, and the README does not offer one. The project is a packaged desktop application rather than a library, so the intended route is the published installer, whose home is the app store listing at apps.wordpress.com/desktop. The releases attached to the repository are the packaged artifacts, tagged with the WP-Desktop prefix and the application version, and the change list in the README is the release note for those artifacts. If your goal is to run the app, take the installer; if your goal is to modify it, the README names the exact place to work, the desktop directory in the WP-Calypso repository on the trunk branch, where the Electron application, its bundler configuration and its tests live. The value of this repository to a developer is therefore navigational, pointing at the version that shipped and the tree that changed, rather than executable.

Editorial conclusion

Anyone trying to build, patch or contribute to the WordPress.com desktop app should clone the WP-Calypso repository and work under its desktop directory, since wp-desktop itself carries a single README and exists for deployment. Reading this repo still has value if you want the changelog of what shipped, but it is the wrong place to look for build scripts, dependencies or issue tracking, since the README directs all issues to WP-Calypso. The concrete next step is to open the desktop tree at github.com/Automattic/wp-calypso/tree/trunk/desktop and confirm your change lands there before filing anything against this repository.

Frequently asked questions

Official sources

1. Automattic/wp-desktop on GitHub
2. Issues
3. Project website
4. README
5. Releases