The WaveDrom editor is a thin shell around the wavedrom engine, and its release is a two stage copy

The editor renders WaveJSON into timing diagrams in real time

WaveDromEditor is a real-time editor of digital timing diagrams, built on two separate upstream pieces: the WaveDrom engine, and the WaveJSON format that the engine consumes. The word real-time carries the design here. A diagram is described as data rather than drawn by hand, so the editor can update the picture as you type and the text stays the primary artifact. That is a meaningful difference from a general purpose drawing tool, where the output is a picture of a circuit and the description of the signals is lost. The editor is served as a page at wavedrom.com/editor.html, the site root carries a tutorial with more examples at wavedrom.com/tutorial.html, and the repository itself contains the static site assets. The top level tree shows the shape of the thing: editor.html and editor.js hold the editor itself, init.js holds its initialisation, tutorial.html and tutorial2.html plus tutorial.css and impress.html are the documentation pages, and skins, css, images, scripts, privacy and test sit alongside wavedrom.min.js.

wavedrom.min.js and the skins are vendored copies of an npm package

The single most important structural fact about this repository is that it does not contain the rendering engine it uses. The rendering engine, wavedrom.min.js, and the skins under skins/*.js are vendored copies of the wavedrom npm package. In package.json the wavedrom dependency is declared at ^3.7.0, which matches the editor's own version of 3.7.0, so the vendored copy and the declared dependency are meant to track each other. That tracking is a manual process, which the project documents under the heading for updating the bundled engine. You refresh the vendored files after bumping the dependency in package.json by installing and copying the files out of node_modules.

npm install
cp node_modules/wavedrom/wavedrom.min.js wavedrom.min.js
cp node_modules/wavedrom/skins/*.js skins/

Read this as a design consequence rather than an accident. Because the engine arrives as a build artifact copied into the tree, the editor repository and the engine repository can release independently, and the editor can serve a static page with no runtime dependency resolution. The cost is that the copy can drift from the package unless someone runs the copy step, which is why the version numbers are set to match.

Building the desktop application is a shell script that downloads NW.js runtimes

The desktop application is packaged with NW.js for Windows, Mac and Linux, and the build is driven by build-wde.sh rather than by a bundler. The npm run build script, which package.json defines as ./build-wde.sh, stages the app sources into src, downloads the matching NW.js runtimes, and produces distributable packages under build. The output names are templated on the version and the platform, and the project lists four of them: a linux x64 tarball, a win x64 zip, an osx x64 zip and an osx arm64 zip. The NW.js version and the app version are set at the bottom of build-wde.sh, and the documented invocation passes both on the command line.

bash build.sh --name wavedrom-editor --nwversion v0.115.0 --version v3.7.0

The instruction after that line is short and important: update both values when bumping versions. This is a shell script wrapper rather than a declarative build, so the version story is spread across the script and the two package.json files instead of living in one place. The WaveDromEditor directory at the top of the tree is the application source that gets staged, and the script is the only piece you need to change to move to a newer NW.js runtime.

A release is a tag plus a gh release create with four artifact globs

The desktop release path is documented as a numbered sequence of steps, and it reads like a runbook. First you bump the version in package.json and in WaveDromEditor/package.json, and you update the version argument, and the nwversion argument if needed, in build-wde.sh. Then you build the packages, then you tag the release, then you publish the artifacts to GitHub Releases with the gh CLI.

npm run build
git tag v3.7.0
git push origin v3.7.0

The publish step passes the built files to gh release create, with a title matching the tag and a notes file.

gh release create v3.7.0 \
  build/wavedrom-editor-v3.7.0-*.tar.gz \
  build/wavedrom-editor-v3.7.0-*.zip \
  --title "v3.7.0" \
  --notes-file TMP_RELEASE_NOTES.md

Two details are worth noting for anyone automating this. The globs cover the tarball and the zips together, so the same command works for all four platforms. And the release notes come from a scratch file named TMP_RELEASE_NOTES.md, which is created and removed outside the documented steps, so it is a piece of the process you will have to supply yourself. The web editor, by contrast, is not released through this pipeline at all, since it is simply the static site in the repository.

Development needs Node 18 or newer, and npm test is an eslint run over two files

The development setup is short enough to state in full. You install Node.js, version 18 or newer recommended, either from nodejs.org or through nvm. Then npm install sets up the development environment, and npm test lints the editor sources.

npm install
npm test

That last part is worth a second look, because the test script is not a unit test suite. In package.json, test is defined as eslint editor.js init.js, so the only automated check defined in this repository is a lint pass over the two main editor scripts. The eslint configuration extends a shared @drom/eslint-config preset, and the devDependencies list codemirror at ^5.65.18 alongside eslint at ^8.57.1, which tells you the editor uses CodeMirror 5 for text editing. The repository also carries a test directory and a service-worker.js at the top level, so there is more in the tree than the two linted files, but the package manifest defines exactly one script for verification.

The repository serves a site, so it is more than the editor page

It is easy to read wavedrom.github.io as the editor and stop there, but the tree shows a small site. Alongside editor.html there is index.html, tutorial.html, tutorial2.html and impress.html, with tutorial.css at the root and an impress directory alongside the css, images, scripts, privacy and test directories. There is a CNAME file at the root, which is the standard mechanism for pointing a domain at a GitHub Pages site, and a manifest.json for the web application manifest, plus a service-worker.js. The privacy directory has a clear purpose given that the site is a public editor. The impress directory and the impress.html page sit alongside the tutorial pages at the root of the tree. None of this is the engine, and none of it is packaged into the desktop application, so the repository serves two audiences that share only the editor code.

A vendored engine means a fork here does not change how other tools render

The clearest limitation follows from the architecture. Because the engine is a copy pulled from the wavedrom npm package, changes to rendering behaviour made in this repository are local to the editor. Anyone embedding the wavedrom package in their own page, or any other tool reading the same WaveJSON, will keep the behaviour of the published package. For an engineer who wants a different diagram style or a new waveform type, that is the wrong place to work, and the README points to the engine repository for that. The same constraint applies to the format itself, since WaveJSON is specified in a separate schema repository, so the vocabulary of the format is not defined here either. The second limitation is about verification: with test defined as a lint run over two files, there is no automated check in this repository that a change to the editor still renders the same diagrams, so regressions in output are caught by eye rather than by a suite.

Editorial conclusion

This repository suits a hardware or firmware engineer who wants to sketch a digital timing diagram in the browser and keep the result as text in a WaveJSON source, and it suits a team that needs the same tool offline, because the desktop build packages the editor as an NW.js application. It is not the place to work on the rendering engine itself, since wavedrom.min.js and the skins are vendored copies of the separate wavedrom npm package, and a fork here does not change how diagrams render elsewhere. Before using the desktop build, check the packaged artifact names against your platform, since the build produces separate archives for linux x64, win x64, osx x64 and osx arm64. The project is MIT licensed, the latest release is v3.7.0 from 2026-09-01, and the last push was on 2026-09-01.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wavedrom/wavedrom.github.io on GitHub