DEV Community

Cover image for Stop Fighting with Symlinks: Why I Built a Fast Local Sync Tool in Rust
yoosef alipour
yoosef alipour

Posted on

Stop Fighting with Symlinks: Why I Built a Fast Local Sync Tool in Rust

#rust #webdev #programming #opensource

If you have ever developed a modular system, a mono-repo, or multiple interdependent packages locally, you know the exact pain: local package linking is broken.

Whether it's npm link, Composer paths, or manual symlinks, something always fails:

  • Nested dependencies get confused or resolve to the wrong directory.
  • File watchers crash or ignore symlinked events.
  • Docker containers refuse to follow links across host mounts.
  • Build artifacts leak into the wrong places.

After spending countless hours debugging ghost bugs that only existed because of broken symlinks, I decided to fix it properly.

The Goal: Instant Mirroring Without the Hassle

Instead of relying on fragile OS-level symlinks, what if we could mirror local packages into dependent projects seamlessly, blazing fast, and without breaking build tools?

That’s why I built linkd — a lightweight synchronization tool written in Rust designed specifically for local package development.

Why Rust?

To make local syncing invisible, it had to meet three strict criteria:

  1. Zero latency: File changes must propagate before your test runner or compiler kicks in.
  2. Minimal footprint: A background sync daemon shouldn’t eat 1 GB of RAM like typical Node.js tools.
  3. Cross-platform reliability: Consistent behavior across Linux, macOS, and Windows.

Rust’s concurrency model and the notify ecosystem made it possible to handle file system events efficiently while keeping resource usage near zero.

Getting Started

Everything you need to install, configure, and integrate linkd into your workflow is available in the documentation:

👉 Read the Official Documentation & Quickstart

Early Results & Feedback

In my daily workflow across multiple packages, build pipelines no longer fail due to symlink resolution, Docker containers stay in sync without weird volume workarounds, and CPU usage stays negligible.

The project is completely open source:

I’d love to get your feedback:

  • How do you currently handle multi-package local development?
  • What edge cases (e.g., git hooks, ignored files, custom watchers) would you like to see supported?

Drop a comment below or open an issue on GitHub!

Top comments (0)