wnr is a strict pomodoro timer with a build for every desktop format

A timer with a point of view

wnr is a work and rest timer, and the repository description is three words long: stricter, prettier, more features, for Windows, macOS and Linux. The project page describes it as a timer app with strong expansibility for computers.

That expansibility is the interesting word. A pomodoro timer is a trivial program to write once, and most of them are a countdown with a beep. What separates a timer people keep for years from one they abandon in a week is usually a small set of opinions about how the timer should behave, and the fact that the user can adjust them without filing a feature request.

The evidence for that is in the file names at the repository root. There is inactivity-duration.js, so how the timer behaves when the machine is idle is a setting rather than an assumption. There is predefined-tasks.js, so the work and rest periods can be named and configured. There is preferences-items.js and a preferences.html with a preferences-renderer.js behind it, so the settings surface is data driven. There is a tourguide.html, a first run walkthrough. There is statistics.html for looking at what you have actually done. And there is a floating.html, a small always-on-top window, plus custom-dialog.html and external-title.html for the edge cases a normal window does not cover.

The audience is a person who has used a pomodoro timer and found it too loose, and the project is a single author project with a Chinese and an English and a Traditional Chinese readme, a website with a Chinese page, and the author reachable by email. The licence is MPL-2.0, and the copyright runs from 2019 to 2026 for Roderick Qiu and other contributors.

Building it, and a script for every packaging format

The build system is yarn, and the readme lists the commands a contributor needs, which is unusual in its granularity.

yarn # install deps

yarn start # launch the app

yarn dir # build executable only

yarn nsis # windows nsis installer

yarn 7zip # windows 7zip protable version

yarn mac # macos

yarn linux # linux

yarn appimage # linux AppImage

Every one of those is a thin wrapper around a script in the res/builder/ directory, and the manifest shows the pattern: each sets NODE_ENV and runs a builder file, so the dev build is cross-env NODE_ENV=development electron ., the NSIS installer is cross-env NODE_ENV=production node ./res/builder/nsis.js, the portable Windows build is the 7zip script with the portable environment, and there are further entries for the macOS build, the Linux build, the AppImage, a directory-only build, a Windows directory build and a Microsoft Store build.

That is seven outputs from one source tree, and it explains why the distribution channels in the readme are as varied as they are. There are GitHub releases for Windows and macOS, a Softpedia listing for Windows, and mirror links through Baidu netdisk and a Lanzou cloud download, which are the channels that work well inside China. The app identifier is com.scrisstudio.wnr and the product name is wnr, and both are set in the packaging configuration.

The dependencies are pinned to exact versions rather than ranges, which for an application that ships to end users is the right call: bootstrap 4.6.2, jquery 3.7.1, electron-store 8.2.0, keytar 7.9.0 and the rest. The development dependencies are electron 22.3.27 and electron-builder 26.0.12, and the electron version is worth noticing, because it is several major versions behind current releases and it is the single biggest constraint on what the app can use.

The application is a set of plain files, not a framework

Looking at the top level of the repository explains a lot about how the app is put together, and it is unusual for an Electron application of this size.

There is no build step for the renderer. The root contains index.html, timer.html, preferences.html, settings-window.html, statistics.html, tourguide.html, floating.html, custom-dialog.html, external-title.html, placeholder.html and about.html, with style.css and loader.css, and the behaviour lives in correspondingly named JavaScript files: main.js is the entry point named in the manifest, renderer.js is the main window, preferences-renderer.js is the settings window, settings-window.js is the separate window handling, updater.js and update.json are the update mechanism, update-language.js handles the language updates, webdav-sync.js is the synchronisation, theme.js is the theming, supporter.js is the sponsorship surface, and inactivity-duration.js and predefined-tasks.js are the timer behaviour as data.

So the app is a set of HTML pages with scripts attached, which is what Electron was for before the ecosystem moved to frameworks. For a small utility that one person maintains, that is a defensible choice: there is no framework to upgrade and no component tree to reason about, and the whole program is readable as files you can open in an editor.

Two features are worth calling out because they are not obvious from the name. The webdav-sync.js file means the app can synchronise its state through WebDAV, which for a timer that tracks your day is how the data follows you between machines without a server account. And the updater.js and update.json pair, together with update-language.js, means the app updates itself and can update its translations separately, which is the mechanism behind a project that ships a dozen languages.

The test setup is also worth noting, because it is modern even though the app is not: the test script is node --test test/*.test.js, which is the Node built-in test runner with no test framework dependency at all, and the repository has a test/ directory alongside a DEVELOPMENT_GUIDE.md that describes the workflow contributors are expected to follow.

Localisation is a documented path, not an accident

The readme has a section for adding a language, and it points at a guide in the locales/ directory rather than leaving it to inference.

That matters more here than in most projects, because the app has a dozen or more interface strings and a settings screen where a mistranslated label is worse than an untranslated one. The localisation runs through the i18n-node package, the internationalisation library in the dependency list, and the locales/ directory holds the translation files.

The project also maintains its own readme in three languages, English, Simplified Chinese and Traditional Chinese, which is a small but telling piece of information about who the user base is. And the website has a Chinese page alongside the English one.

There is a fourth language mechanism that is separate from the interface translations, and it is the more interesting one. The update-language.js file, sitting next to updater.js and update.json, suggests that the language packs are updated independently of the application, which is the pattern a project with a lot of translators and an occasional release needs. The reason is not a mystery: an interface string change should not require a new binary, and a translator should not need a build environment.

The contributing section is written in the same practical tone. Feature requests and bugs go to the issue tracker, pull requests are welcome, and a new language should start by reading the guide.

The NOTICE file, and what the dependency list says

The licensing section of this repository is more thorough than most, and it is worth reading whatever you use the app for.

The project is licensed under the MPL 2.0 licence, and the copyright is 2019 to 2026 for Roderick Qiu and other contributors. The readme then points to a NOTICE.md file for the full text of the licences of everything bundled, and says that it is included in every copy of wnr.

That file lists the dependencies and their licences individually: node-shi and cmd-or-ctrl, both the author's own projects and both MIT, node-auto-launch, Teamwork, MIT, compare-version, kevva, MIT, electron-store, sindresorhus, MIT, i18n-node, mashpie, MIT, crypto-js, brix, MIT, copy-to-clipboard, sudodoki, MIT, request, Apache-2.0, winreg, BSD 2-Clause, electron and electron-builder, MIT, jquery, MIT, bootstrap, MIT, iconfont from the Alibaba MUX set with a note to check the site, dotenv, BSD-2-Clause, electron-debug, node-fetch, node-notifier, popper.js, schart.js, cross-env, and Node itself.

The list tells you a lot about the app. It uses jQuery and Bootstrap 4 for the interface, schart.js for the statistics charts, a colour picker library for whatever colour setting exists, a native module for the system keychain, one for auto launch at login, one for desktop notifications, and copy to clipboard for the copy buttons.

The presence of keytar deserves a note, because it is a native module that talks to the operating system's credential store, and native modules are the usual reason an Electron app fails to build on a new platform. Building seven packaging formats, each with its own native module requirements, is the practical cost of that design, and the build scripts in res/builder/ are where that cost is paid.

Release pace and what the project does not promise

The release history shows a project that ships often and slowly changes direction. The recent tags are v1.32.0 on 2026-02-06, v1.33.0 on 2026-07-28 and v1.34.0 on 2026-08-18, and the last push was on 2026-08-18, the same day as the newest tag. The repository is not archived.

The gaps between those minor versions are months rather than weeks, which is a different profile from a release every few days. It is the profile of a project where features land when the author has time, and where the version number grows when a batch of work is finished rather than on a schedule.

What the project does not promise is worth noting, because the marketing in the description is short and confident while the documentation is not. There is no support commitment, no issue response time, and the contact offered is a personal email address. The downloads are on personal release pages and third party mirrors rather than on a store with a review process, and the Microsoft Store build script exists but the readme's download section points at GitHub, Softpedia and two Chinese file hosts.

For a user, the practical read is that wnr is a well built personal project rather than a product, and that the value is in the timer being adjustable and the code being readable rather than in anyone being on the other end of a support request. The archived flag is not set, the last push is recent, and the project is at version 1.34.0 with a licence that lets you redistribute a modified build under the MPL terms.

Editorial conclusion

wnr suits someone who wants a pomodoro timer they can extend, since the predefined tasks, the inactivity behaviour and the settings are all in plain JavaScript files in the repository rather than compiled away, and it suits a user who wants the same timer on all three desktop platforms. It is the wrong choice if you want a modern, well maintained desktop shell, because the Electron version in the manifest is 22, which is old, and a poor match if you need a mobile or browser version, since this is a desktop application. Before building it, read NOTICE.md, because the bundled dependencies carry their own licences, and read the development guide, since the project expects contributors to follow a documented workflow for adding a language.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. RoderickQiu/wnr on GitHub