Compatibility
Published
Configuration that arrives from a file on disk feels safer than configuration that arrives from the environment. It is versioned, it is reviewable, it is right there in the repository. But the two have exactly the same property where protection is concerned: the keys are written by something that is not your build, and JSON.parse hands you back an object whose property names came from that file verbatim. Reading them is ordinary property access, and ordinary property access is what member renaming rewrites.
What was measured
One sample file and two fixtures: a settings file of the kind a user edits, and a package manifest of the kind a build tool generates. The sample reads flat keys, a nested key one level down, the version string a crash reporter tags events with, and a dependency map. It then does the two things every config loader does -- merges the parsed object over a literal of defaults, and runs a required-key validator driven by a list of key names held as strings.
Neither fixture is written by the sample. That is the entire basis of the measurement. A config module tested by building its own config object in the same file proves only that renaming is internally consistent, which was never in question. Here the keys cross a real boundary: they are authored in JSON, on disk, by a party that is not recompiled when the bundle is.
The base column is clean. On the default target, the modern target, the gate profile, the modern gate profile and the string-transform profile, the sample's output matched the unprotected original exactly -- every value, the nested read, the merged result, the validator's verdict and the serialised output. Protection on its own does not touch how configuration files are read.
A config file that is present, valid, and entirely ignored
With member renaming on and a pattern matching three of the settings keys, every direct read came back undefined, and the merged configuration collapsed onto its defaults: effective=https://api.example.com/v2|5|true became effective=https://localhost:9/|0|false.
Read that line slowly, because it is worse than a crash. The endpoint fell back to a localhost placeholder, the retry count fell to zero, and verbose logging switched off -- three settings the operator explicitly configured, silently replaced by the values the code ships with when it finds no configuration at all. The file was found. It parsed. It was valid. Nothing in the run reports a problem.
The mechanism is worth spelling out because it is not the obvious one. The parsed object keeps its original keys, because JSON.parse builds properties out of the text it read. What got renamed is the defaults literal in the source, and the merge loop iterates over that literal's keys. So the loop asks the parsed config for the generated names, finds nothing, and takes the default for every single field. The user's file and the running program are looking at the same object and spelling every name differently.
The validator passes precisely because it is doing its job
The sharpest detail in this pass is that the required-key check reported missing=none, unchanged, in the same run in which every value had silently reverted to a default.
That validator is written the way validators are written: a list of required key names as strings, tested against the parsed object. Both halves of that test are untouched by renaming -- the strings are data, and the parsed object still carries the file's original keys -- so it looks at the configuration, sees every required key present, and correctly reports that nothing is missing. It is not broken. It is answering a different question from the one the rest of the program is asking.
This is the mirror image of a result measured on this site for environment variables, where a dynamic guard reported present variables as missing while direct reads stayed correct. Same defect family, opposite direction, and the direction is decided by which side of the contract the renamed literal sits on. The practical lesson is the uncomfortable one: the check you would reach for to catch a misconfigured build is structurally incapable of catching this, and it will keep printing a clean bill of health.
The loud arms, and what leaks into the output
Not every arm was quiet, and the loud ones are the good news. A pattern matching the nested container and its child threw TypeError: Cannot read properties of undefined on the first nested read and took the rest of the file with it. A pattern matching the dependency map did the same. When a renamed name is a container that something is then read out of, the failure is immediate and unmissable at startup. It is only when the renamed name holds a leaf value that the program continues with the wrong one.
Two arms show the partial cases that are hardest to reason about. A pattern matching a single settings key left the other two correct and reverted only that one, producing a configuration that is right in most respects and wrong in one -- the state that generates the longest incident reviews. And a pattern matching the manifest's version key produced version=undefined while the package name beside it stayed correct, which means every crash report and analytics event from that build is tagged with an undefined release.
One more thing leaves the process. The sample serialises part of its merged config back out, as any tool that writes an effective-configuration file or logs its settings does. That output went from {"endpoint":"...","retries":5} to {"_0x1":"https://localhost:9/","_0x2":0}. The generated names are now in a file, or a log line, or a support bundle -- carrying both the wrong values and the internal spelling.
What this means in practice
Protection does not break configuration files. That is measured on five profiles, and if you run a default configuration you can stop here.
With member renaming on, the rule follows from who writes the name. Keys that live in a JSON file -- your own settings schema, a package manifest, a lockfile, anything a user or a tool edits -- are contracts your build does not own, and they belong in the reserved list rather than in the rename pattern. Anchoring the pattern to identifiers distinctive to your application handles most of this automatically, but config schemas are the case where generic words like endpoint, retries, region and version show up most often, so it is worth an explicit look rather than trusting the anchor.
The verification is a single line and it must be run against the protected artifact. Print the effective configuration at startup and compare it to the file. If a value you can see in the file is not in the printout, the name was renamed. Do not use the required-key validator for this -- as measured above, it will report success while every value is a default, and that is not a bug in the validator but a consequence of it reading the file correctly.
Frequently asked questions
Does obfuscation break JSON config files?
Not in the default configuration. A loader that reads flat keys, a nested key, a version string and a dependency map, merges over defaults and runs a required-key validator produced identical output on all five protection profiles measured. Config files only become a surface when member renaming is enabled and the pattern matches their keys.
Why does my config file appear to be ignored after protection?
Because the defaults literal in your source was renamed and the parsed file was not. JSON.parse builds properties from the text it read, so the parsed object keeps the original keys, while the merge loop iterates the renamed names of the defaults object. It finds nothing under those names and takes the default for every field -- measured as a full collapse from configured values to placeholder defaults.
Why does my required-key validation still pass?
Because it is reading the file correctly. A validator built from a list of key names as strings tested against the parsed object touches nothing that renaming rewrites, so it sees every required key present and reports none missing. In the measured run it printed missing=none while every effective value had reverted to a default.
Is package.json affected too?
Yes, in the same way. A pattern matching the version key produced version=undefined while the package name beside it stayed correct, which tags every crash report and analytics event from that build with an undefined release. Manifest keys are written by npm and by your tooling, not by your bundle.
Does a renamed nested config key fail loudly or quietly?
Loudly, and that is the better outcome. Renaming a container object produced a TypeError on the first nested read and stopped the program at startup. The quiet failures happen when the renamed name holds a leaf value, because the program simply continues with the default or with undefined.
Can generated names end up in files my program writes?
Yes. The sample serialises part of its merged configuration back out, as any tool that writes an effective-config file or logs its settings does, and that output changed from real key names to generated ones. Those names then appear in logs and support bundles alongside the wrong values.
How do I keep config files working with member renaming on?
Treat every key that appears in a file on disk as a name your build does not own and put it in the reserved list. Then verify against the protected artifact rather than the source: print the effective configuration at startup and compare it with the file. Do not rely on required-key validation, which passes in exactly this failure.
Related reading