Dendron Revival
I've been using Dendron since late 2021 - a note-taking tool built for developers that clicked with how I wanted to organize personal knowledge.
Development slowed in late 2022, and by early 2023, the founder officially announced they were stepping away. For over two years, the project sat abandoned. In 2025, I finally decided to fork it, because I wanted specific features and nobody else had picked it up yet. What I found when I dove into the codebase explained a lot about why development had stalled: layers of architectural decisions had created a maintenance nightmare.
This is what it took to make it workable again.
The Starting Point
The repository I inherited was in rough shape. The head of main didn't compile, and the setup scripts - assuming they had ever worked - certainly didn't anymore. Just getting a build running meant punching holes in my firewall for dependencies on Sentry and Segment that were baked into the compilation process.
The build itself was a nightmare: it required bootstrapping steps, partial builds in specific orders, and manually shuffling files between directories. The package.json was littered with scripts that programmatically manipulated git stashes and ran pre-commit hooks in ways that felt fragile and opaque. Nearly every build step relied on custom scripts using execa to shell out commands rather than using proper tooling.
Tying it all together was a hard dependency on a local Verdaccio instance, complete with hardcoded timeouts and the assumption it would just... be running. It was the kind of setup that works on exactly one person's machine - until it doesn't.
Getting To "Working"
My first priority was establishing a reproducible development environment. I added a .devcontainer configuration - my standard starting point for any project. The value proposition is simple: anyone should be able to clone the repository and have a fully configured environment in minutes, with all dependencies, tooling, and versions locked down. No "works on my machine" problems, no multi-page setup docs that go stale. For a project that had been abandoned and would need to attract any potential contributors from scratch, this wasn't optional.
With the environment sorted, I needed to claim ownership of the packages. I changed all the package names from @dendronhq to my own namespace and published initial versions to npm. This wasn't just bureaucratic - it meant I could start iterating on fixes and publish working versions without worrying about namespace conflicts or waiting for access I'd never get. The project was officially mine to maintain.
Simplifying the Build
With a working environment in place, I could finally address the build process itself. First order of business: ripping out all the telemetry. Segment, Sentry - none of it made sense for a fork I was maintaining for myself and a handful of users. I wasn't running a YC-backed product trying to measure engagement metrics. Beyond the philosophical mismatch, the telemetry meant I couldn't build without poking holes in my firewall, which was a non-starter. The cherry on top? Even the command to disable telemetry sent telemetry. Out it went.
Next was tackling Lerna. The project used Lerna to manage its monorepo, which added a thick layer of abstraction and tooling overhead for what Yarn workspaces could handle natively. Lerna had been essential in the early days of monorepo tooling, but by 2025 it was just extra complexity. I migrated everything to Yarn workspaces - leaner, better integrated with the package manager we were already using, and one less dependency to maintain. The build got faster and the configuration got simpler.
Developer Ergonomics
Even as the only developer on the project, I wasn't interested in fighting the tooling every time I needed to make a change. The bootstrap and setup scripts were the next target.
The CLI package - something end users would download from npm - had become polluted with internal developer commands. Some of these interfaced directly with npm in ways that required the original org's publishing keys, which meant the CLI had to be built just to build other parts of the system. I gutted all the developer-specific commands and stripped it back to a purely end-user tool. No more circular dependencies in the build process.
I also stopped hedging bets on platform compatibility. The codebase was full of rimraf, cross-env, and Node.js scripts that just used execa to shell out commands anyway. I wasn't targeting Windows, so I replaced all of it with standard Linux commands - rm, rsync, the tools already in the environment. Less abstraction, less to break.
Finally, I tackled the test setup. All tests had been dumped into one giant workspace, which meant running tests for a single package required running the entire suite. I moved tests into their respective workspaces and updated Jest to support running them individually. Suddenly, the feedback loop for changes went from minutes to seconds.
Actually Adding Features
All of that cleanup work wasn't the goal - it was the prerequisite. What I actually wanted was to modernize the dependencies and add features that had been impossible under the old architecture.
First: upgrading to Node 18. The project had been stuck on Node 16, partly because of OpenSSL changes in Node 17+ that broke the build without the --legacy-ssl-provider flag. That flag was a band-aid, not a solution. With the build process cleaned up and the dependency hell untangled, I could move to Node 18 cleanly - no flags, no workarounds.
That unlocked the real prize: Mermaid.js v11. The project was stuck on v8, which was years old at this point. v11 required Node 18, which meant it had been completely off the table. Mermaid diagram support was the main reason I'd forked the project in the first place - I wanted better diagrams in my notes, and v11 had significant improvements to rendering and syntax. This was what all the prior work had been building toward.
Why Nobody Else Picked It Up
Looking back, it's clear why Dendron sat abandoned for two years despite having users who wanted it to continue. The barrier to entry wasn't just high - it was deliberately obscured by layers of unnecessary complexity. Want to upgrade Node and a single dependency? That'll require rewriting the build system, untangling a monorepo tool that shouldn't have been there, removing hardcoded infrastructure assumptions, and restructuring how tests run.
For anyone evaluating whether to fork and maintain an abandoned project, that's an impossible cost-benefit calculation. The project wasn't just unmaintained - it was unmaintainable. Every architectural decision had compounded into a system where even trivial changes required understanding and reworking significant portions of the infrastructure. I went into this wanting better Mermaid diagrams. I got a masterclass in technical debt and what happens when complexity accumulates without anyone asking whether it's actually necessary.
If there's a lesson here, it's this: the maintenance burden you create today is the contributor barrier of tomorrow. Keep it simple, or eventually nobody - including you - will be able to move it forward.
Backlinks