RepoDNA v1.3.3: Safer WebAssembly CLI, Better Artifact Protection, and Security Fixes
Building a developer tool is not just about supporting more programming languages, generating more metrics, or introducing new visualizations.
It is also about what happens when something goes wrong.
What happens when a user supplies an invalid command-line option? What if a report output accidentally points to the analysis file being read? What should a documentation generator do when a link contains malformed encoding?
These are the kinds of questions addressed in RepoDNA v1.3.3, the latest stable release of my open-source, local-first repository intelligence project.
What is RepoDNA?
RepoDNA helps developers understand a software repository through evidence-backed analysis.
It explores repository architecture, module dependencies, Git history, code complexity, security signals, development activity, and more.
It also produces shareable Project DNA cards, reports, and comparisons.
The project is built around Rust, TypeScript, React, and WebAssembly. Its analysis is designed to work locally, without requiring source-code uploads.
- Stricter WebAssembly CLI argument validation
RepoDNA includes a WebAssembly distribution that can run analysis and reporting operations without installing a platform-specific native executable.
In v1.3.3, the repodna-wasm command-line launcher has improved validation.
The launcher now rejects invalid input conditions such as missing option values, unsupported report formats, unsupported themes, unsupported privacy presets, flags used with the wrong command, and repeated flags.
These errors are detected before the WebAssembly engine is loaded.
This makes incorrect command-line usage more predictable and easier to diagnose.
- Protecting analysis files from accidental replacement
One of the most important changes in this release concerns file safety.
When producing a report or Project DNA card, users specify an analysis artifact and an output destination.
A mistake in those paths should not destroy the original analysis.
RepoDNA v1.3.3 adds safeguards that prevent the WebAssembly CLI from replacing its input analysis file with the generated report or card.
The protection also covers hard links that refer to the same underlying file.
This is a small but meaningful improvement to artifact integrity.
- More reliable documentation generation
The documentation-site builder now handles relative paths in raw HTML more consistently.
Links and images using either single-quoted or double-quoted href and src attributes are handled correctly.
The builder also reports malformed percent-encoding in documentation links instead of crashing.
For documentation maintainers, actionable build diagnostics are much more useful than an unexpected termination.
- Rust security dependency updates
The release upgrades rustls to version 0.23.46 in both Rust lockfiles.
The update addresses the following advisories:
RUSTSEC-2026-0346
RUSTSEC-2026-0347
RUSTSEC-2026-0348
RUSTSEC-2026-0349
Dependency maintenance is an essential part of maintaining an open-source developer tool, particularly one distributed across several platforms.
- Regression tests
The release also adds regression coverage for WebAssembly CLI argument handling and analysis-file preservation.
These tests can run without building the entire WebAssembly engine.
Documentation-site tests now cover raw HTML links and malformed URL encodings as well.
The goal is not simply to fix an issue once, but to make it less likely to return.
Using RepoDNA
The web version is available here:
https://sanskarin.github.io/RepoDNA/
You can explore the built-in demonstration or analyze a local folder or archive directly in the browser.
For a command-line installation through npm:
npm install --global @sanskarin/repodna
To use the WebAssembly package:
npx @sanskarin/repodna-wasm analyze .
Platform-specific release downloads are also available for Windows, Linux, and macOS.
What comes next?
RepoDNA continues to evolve as a tool for codebase understanding, architecture exploration, repository history, and evidence-based engineering decisions.
For this release, the priority was correctness, predictable error handling, artifact protection, and security maintenance.
Not every meaningful update needs a large new feature.
Sometimes the most valuable improvement is making an existing tool more dependable.
Links
GitHub: https://github.com/sanskarIN/RepoDNA
v1.3.3 Release: https://github.com/sanskarIN/RepoDNA/releases/tag/v1.3.3
Web version: https://sanskarin.github.io/RepoDNA/
Documentation: https://sanskarin.github.io/RepoDNA/docs/
Source comparison: https://github.com/sanskarIN/RepoDNA/compare/v1.3.2...v1.3.3
If you work with developer tooling, static analysis, repository architecture, or open-source software, I'd be interested to hear your feedback.
RepoDNA — Understand your codebase. See its DNA.
Top comments (2)
Checking for hard links on the input-versus-output path check is an edge case that usually gets missed until someone clobbers an analysis file.
Simple canonical path string comparisons miss cases where two distinct paths resolve to the same underlying inode through a hard link. Opening the destination file with write or truncate permissions destroys the input file before the report finishes rendering.
Comparing device and inode numbers before acquiring the write handle prevents that completely. Catching invalid argument flags before spinning up the WebAssembly runtime also keeps errors immediate instead of paying the runtime initialization penalty on a typo.
Thanks for highlighting this! You’re absolutely right — canonical path comparisons alone aren't sufficient when hard links are involved, since different paths can reference the same underlying file.
This was an important consideration in RepoDNA v1.3.3. The goal was to protect analysis artifacts from accidental overwrites, including hard-link scenarios, while ensuring invalid CLI arguments are rejected before the WebAssembly runtime initializes.
I also agree that validating arguments early improves both performance and the developer experience, especially when a simple typo would otherwise trigger unnecessary runtime initialization.
One area I'm considering for future hardening is how best to handle race conditions between file identity checks and opening the output destination.
I'd be interested in your perspective: would you favor an atomic temporary-file-and-rename strategy, or additional filesystem-level safeguards for this kind of CLI workflow?