{"id":10422,"date":"2026-09-17T07:20:00","date_gmt":"2026-09-17T05:20:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10422"},"modified":"2026-09-09T17:08:50","modified_gmt":"2026-09-09T15:08:50","slug":"comparing-two-gtm-container-exports-normalising-before-the-diff","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/web-development\/comparing-two-gtm-container-exports-normalising-before-the-diff\/","title":{"rendered":"Comparing Two GTM Container Exports: Normalising Before the Diff and What a Line Diff Cannot Show"},"content":{"rendered":"

Comparing two exports of the same configuration is the fastest way to find out what someone changed, and the first attempt almost always produces a result that is useless. There are several hundred differing lines, of which one matters and the rest are the file format talking to itself.<\/p>\n

Everything below is about the gap between those two numbers – what fills it, how to remove it, and what remains invisible even after it is gone.<\/p>\n

\n\"The
Three levels for one change, and a fourth pair that a line comparison calls different and a parser calls identical.<\/figcaption><\/figure>\n

What Fills the Gap<\/h2>\n

Exports are generated, and generators are not obliged to be stable. The same configuration exported twice can differ in the order of object keys, in identifiers assigned at export time, in a fingerprint that is a timestamp, and in whether the file ends with a newline. None of that is a change; all of it is a difference.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Source of noise<\/th>\nWhat it looks like<\/th>\nHow it is removed<\/th>\n<\/tr>\n<\/thead>\n
Key order<\/td>\nwhole blocks marked as changed<\/td>\njq -S .<\/code> sorts keys recursively<\/td>\n<\/tr>\n
Fingerprints, timestamps<\/td>\none changed line per object<\/td>\ndelete the fields before comparing<\/td>\n<\/tr>\n
Export-time identifiers<\/td>\nevery reference differs<\/td>\nthe same – or compare by name instead<\/td>\n<\/tr>\n
Indentation<\/td>\neverything differs<\/td>\njq<\/code> reformats both sides identically<\/td>\n<\/tr>\n
Line endings<\/td>\nevery line differs, and looks identical<\/td>\ndos2unix<\/code>, or the diff tool’s own option<\/td>\n<\/tr>\n
Minification<\/td>\none line differs and says nothing<\/td>\nreformat, then compare<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The line-endings row is the one that costs an hour, because the two lines look exactly the same on screen. A file that has been through a Windows editor differs from its origin in every single line, and every one of those differences is invisible.<\/p>\n

Normalise First, Compare Second<\/h2>\n

The fix is a pipeline rather than a better diff tool. Both files go through the same normalisation, the volatile fields are removed, and only then are the results compared – at which point the diff contains what changed and nothing else.<\/p>\n

norm() {\n  jq -S 'walk(if type == \"object\"\n              then del(.fingerprint, .accountId, .containerVersionId)\n              else . end)' \"$1\"\n}\n\ndiff <(norm alt.json) <(norm neu.json)<\/code><\/pre>\n
walk<\/code> descends into every object, so the fields disappear wherever they occur rather than only at the top level. -S<\/code> sorts the keys of every object, which removes the largest source of noise on its own. What survives both is a change someone made.<\/p>\n
Three Levels, Three Different Answers<\/h2>\n
Line, word and character are not degrees of quality but different questions. A line comparison answers “which lines are not identical”, which is the right question for source code, where a line is roughly a statement. It is the wrong question for a JSON file with one object per line and entirely useless for a minified one, where the whole document is a single line.<\/p>\n
Word level compares tokens and is what makes a one-value change readable. Character level is finer than anyone needs for reading, and it is exactly what is needed when the line is long: in a minified container export, only a character comparison can point at the single boolean that flipped.<\/p>\n
What No Level Can Show<\/h2>\n
A text comparison sees text. Which means three kinds of change stay invisible no matter how fine the granularity gets. A moved block appears as a deletion in one place and an addition in another, with nothing connecting them. A renamed variable used in twelve places appears as twelve unrelated changes rather than one intention. And a value that changed type without changing appearance – \"1\"<\/code> becoming 1<\/code> – is a two-character difference with consequences that no amount of highlighting will convey.<\/p>\n
The opposite case is the one the fourth row of the diagram shows: two files that differ in every line and describe the same object. A comparison of text can only ever answer questions about text, and the question actually being asked – did the configuration change – is a question about structure.<\/p>\n
What to Compare Instead When the Answer Matters<\/h2>\n
For anything with a schema, the honest comparison is between parsed objects rather than between files. jq<\/code> can do it directly: two documents are equal or they are not, and the answer is a single boolean that is not affected by formatting, order or whitespace.<\/p>\n
# are they the same object at all?\njq -e --slurpfile b neu.json '. == $b[0]' alt.json >\/dev\/null && echo \"identical\"\n\n# which top-level keys differ?\njq -n --slurpfile a alt.json --slurpfile b neu.json \\\n  '($a[0] | keys) as $ka | ($b[0] | keys) as $kb\n   | { nur_alt: ($ka - $kb), nur_neu: ($kb - $ka) }'<\/code><\/pre>\n
Which leaves the line comparison the job it is good at: showing a person what someone else did, in a form that reads like the file they will edit. It answers “what should I look at” very well and “is this the same” not at all, and most of the frustration with it comes from asking it the second question.<\/p>\n
\n
Sources<\/h2>\n