DEV Community: Tamer Kalla

The same glob pattern means three different things in one repository

Tamer Kalla — Sun, 06 Sep 2026 16:55:47 +0000

I spent twenty minutes last week convinced my tsconfig was broken.

The pattern was src/**. It works in a .gitignore. It works in every glob library I have ever installed. In tsconfig.json it does nothing at all, and the reason turned out to be that TypeScript rejects it outright:

File specification cannot end in a recursive directory wildcard ('**'): 'src/**'

Not "matched nothing". Rejected. The diagnostic is right there in the output if you go looking, and I had not gone looking, because it had never occurred to me that a glob could be a syntax error in one file and completely ordinary in the next one.

A glob is not one language

Count the places you write a glob pattern in a normal week. I get six without trying:

.gitignore
tsconfig.json, in include and exclude
an ESLint config, which is minimatch underneath
a Vite or rollup config, which is picomatch
lint-staged, which is micromatch
Node itself, path.matchesGlob and fs.glob

Those are six dialects that share a syntax and disagree about what it means. Nothing warns you when you cross from one to another, because each tool answers only for itself, and none of them has any reason to tell you that the other five read your pattern differently.

So I took 25 patterns straight out of config files I actually had lying around, 20 ordinary paths, and asked all six engines every combination. 500 questions, no sampling, same answers on a re-run.

19 of the 25 patterns are not read the same way by all six.
5 of them are refused outright by one engine and accepted by the other five. Every one of those five ends in **.
Of the 400 pattern and path pairs drawn from the patterns that every engine accepts, 48 come back with different answers.
6 patterns are read identically by all six.

Six out of twenty-five. If you have ever written a pattern meant to mean the same thing in your .gitignore and your tsconfig and your bundler config, you had roughly a one in four chance of getting one.

Where the disagreements actually live

Two rules cause most of it.

Dotfiles. src/** matches src/.hidden/file.ts under git. It does not match under minimatch, picomatch, micromatch or Node, because those four skip dotfiles unless you ask for them and git does not. This is the one that bites, because the file you were trying to ignore is usually the dotfile.

Braces. **/*.{ts,tsx} expands in the three npm matchers and in Node. git does not expand braces at all. Neither does tsconfig. So a pattern that is unremarkable in a Vite config quietly matches nothing in a .gitignore, and nothing anywhere tells you.

Put those together on one line and you get the case that started this:

src/** vs src/.hidden/file.ts

  git          match
  micromatch   no match
  minimatch    no match
  node         no match
  picomatch    no match
  typescript   rejected: cannot end in a recursive directory wildcard

Three different answers. One pattern, one path.

Asking all six at once

That output is a command, not a screenshot. I packaged the harness up so it is one line:

npx glob-consensus 'src/**' src/.hidden/file.ts

It exits 0 when every engine agreed and 1 when they did not, so it works in a script. There is a library underneath it if you want the report as data.

It implements no matching logic of its own, deliberately. Every verdict comes from an engine that already exists and that somebody already maintains, which means the answer to "is this correct" is never a matter of my opinion. Two of the six answer about a filesystem rather than about a string, so those two get asked by building a temporary tree of empty files and throwing it away afterwards.

One caveat worth knowing before you read the output: tsconfig filters by file extension as well as by pattern, so a .log file is never included by a tsconfig no matter what you write. That is tsconfig being tsconfig rather than a glob dialect difference, and the report shows it as it is rather than trying to be clever about it.

This is the second time I have built a thing whose whole job is to ask several implementations the same question and print where they disagree. The first was schema-parity, which does it for JSON Schema validators, and the shape keeps being useful for the same reason: the interesting bug is almost never inside one implementation, it is in the gap between two of them that everybody assumed were the same.

It does not tell you which engine is right, because there is no right. They are all correct about themselves. It just stops you spending twenty minutes blaming your tsconfig.

https://www.npmjs.com/package/glob-consensus

A source map is a claim, and nothing checks whether it is true

Tamer Kalla — Sat, 05 Sep 2026 19:15:41 +0000

A source map is a claim about two files: that this position in the built output came from that position in a source file. I had never thought of it as a claim that could be false until a stack trace sent me to a line that had nothing to do with the crash.

The build had gained a step. Something small, a licence banner prepended at the end of the pipeline, after the bundler had already written the map. The bundler was right. The banner was right. The map was now a careful description of a file that no longer existed.

What made it expensive was that nothing anywhere said so. A broken map is still well formed JSON with all the right keys. It parses. It loads. The debugger opens it and shows you a file and a line, with exactly the same confidence it shows you a correct one. There is no error, no warning, no degraded mode. You just get an answer that is wrong, and you spend an afternoon doubting your own reading of the code.

So I went looking for a way to ask a map whether it was still true, and found that three things can be checked without knowing anything at all about the transform that produced it.

A mapping never points past the end of a line. If a map says position 1:26 and line 1 is eighteen characters long, it is describing text that is not there.

A mapping never lands strictly inside an identifier. Generators emit positions at token boundaries, because the two halves of a name are not separately addressable in either file.

And when a mapping carries a name, the original source at that position begins with that name. The map is asserting an identity. Either the identifier is there or the map is wrong, and there is no third answer.

The first thing I did was run those three checks over output I had no reason to doubt, because a checker that flags everything passes every soundness test ever written and is worth nothing. Across bundles from esbuild and files from tsc: 371 mappings, of which 26 carried a name, and not one violation. That number is the reason I trusted anything that came after it.

Then I took the same bundle and the same map, and prepended three lines.

$ npx sourcemap-truth --demo

dist/bundle.min.js   93 mappings, 2 sources

  generated side    5 of 93 land on a token,   88 do not
  original side    93 of 93 land on a token,    0 do not
  names            26 of 26 are at the position the map gives

  1:6    inside an identifier
  1:22   past the end of that line
  1:26   past the end of that line

  The map is not true of this file. Something changed dist/bundle.min.js
  after the map was written.

Eighty-eight of ninety-three. Nothing about the file on disk hints at that, and the debugger will not mention it.

The shape of the failure tells you where to look, which turned out to be the part I use most. In the run above the original side is perfect and the generated side collapsed, which means the output moved after the map was written. Shift the sources instead and it inverts: every position still checks out and all 26 names point at the wrong identifier. Those are different bugs in different steps, and you can tell which one you have before you start bisecting the pipeline.

There is one thing it deliberately does not do, and it took a wrong turn to get there. My first version counted a mapping that landed on whitespace as a fault. That felt reasonable until I ran it against tsc, which deliberately maps the space after a keyword: 14 times in 122 mappings on one small file. Correct output scored 108 of 122. A checker that calls the compiler wrong is not measuring the compiler, it is measuring itself, so whitespace targets are not faults and the tool says nothing about them.

The other thing it refuses to do is guess. A map whose sources carry no content cannot be shown true or untrue, and the report says unchecked rather than passing, with its own exit code. Keeping "this disagreed" apart from "nobody could tell" is the single decision I would keep if I had to throw the rest away. Collapsing them is how a checker ends up certifying everything it is handed.

It is one function if you want it in CI, and one command if you just want to know:

npx sourcemap-truth dist/index.js

Zero for a map that is true, one for a map that is not, two for one nobody could check.

The same question turns up in a lot of places once you start looking for it. It is roughly how I ended up writing schema-parity a while back, for whether a generated JSON Schema still accepts what the validator it came from accepts. Different artifacts, same shape of doubt: two things that are supposed to describe each other, and nothing that ever checks.

https://www.npmjs.com/package/sourcemap-truth