The bug: a JSON error with no obvious cause
Adding a biometric authentication plugin to a Tauri desktop app, the build started failing with this:
failed to parse JSON: expected value at line 1 column 1: expected value at line 1 column 1
No file path. No line number in our own code. Just a generic parse failure, somewhere inside Tauri's own build process.
First instinct: check the obvious file
The error mentioned "capabilities" — Tauri's permission system — so the first suspect was the capability file itself. Opened it, read it carefully, looked completely valid. Removed the biometry-specific permissions entirely, leaving just the two that had worked before. Same error.
Second instinct: it's the plugin's fault
Tried a different version of the plugin. Same error. Tried pulling the plugin directly from its GitHub source instead of the published package, in case the published version was missing a file. Same error, byte for byte.
Three genuinely different attempts, identical failure. Worth sitting with that for a moment: when multiple different versions of the same dependency all fail identically, the dependency itself becomes a much less likely suspect than something upstream of it.
The actual test that mattered
Rather than keep guessing at the plugin, the real diagnostic question became: does a completely fresh, untouched Tauri project — zero modifications — also fail this same way, on this same machine?
It didn't. A brand-new scaffold built and ran fine immediately.
That single test eliminated an entire category of hypotheses at once. Not the Rust toolchain. Not the Tauri version. Not the operating system. Something specific to this project, that a fresh one didn't have.
Finding the actual difference
With a genuinely working reference project sitting right there, the fastest path forward was direct comparison rather than more guessing. Cargo.toml: identical in structure. tauri.conf.json: identical. The capabilities file: nearly identical, except the broken project was missing one line the working one still had — a schema reference we'd removed earlier while chasing a different, unrelated hypothesis.
Copying the working project's capability file over, byte for byte, fixed it immediately.
What actually happened
The most likely explanation: repeated automated rewrites of that config file (through a terminal, across several rounds of troubleshooting) introduced a subtle encoding artifact — invisible on screen, but different from a byte-for-byte perspective. Not something a visual read-through would ever catch.
The actual lesson
"I read the file and it looks fine" is a weaker claim than it feels like in the moment. Text that displays correctly and text that is byte-for-byte correct are different things, and most tools happily show you the first while hiding the second.
When a config-driven failure resists every content-level fix, the more productive question isn't "what's wrong with what I wrote" — it's "is there a known-good reference I can diff against directly, rather than re-reading my own version one more time." A fresh scaffold, a fresh clone, a fresh anything genuinely different from what's already been touched repeatedly, is worth more than another careful read-through.
