The generalisation is worth more than this particular bug, because you will meet the shape again: an error that names the innocent party.
It happens whenever a tool rewrites your code before it runs, bundlers, transpilers, minifiers, module systems. The rewriting is what produces the identifier in the message, so the message describes the output, and the output is made of your dependencies' names. The thing that did the rewriting never signs its work.
A short test that has never let me down:
- Did the named thing change? Check the lockfile, not your memory. If it did not, it is not the cause, whatever the message says.
- Does the fault survive with the optimisation off? Splitting, minifying, tree-shaking, whatever the tool offers. If turning one off fixes it, you have named the layer.
- What else moved in that upgrade? One line in your manifest is rarely one package. This is where the answer usually is.
Step three is the one people skip, and it is the one that pays. A dependency you have never heard of, that you did not choose and cannot see in your manifest, is doing most of the work in a modern build: and it ships on its own schedule.
On the good news: a bug this visible, in a widely used combination, tends to be fixed upstream within a couple of releases. Search the bundler's tracker rather than the build tool's, and search for the identifier rather than a description of the symptom. Mangled names are unique strings, which makes them the best search terms you will ever get out of a bad error message.