A Shadow Over Canberra: Photo by the author.

I’ve been coding for almost 40 years, so why do I still do stupid things?

I just tracked down a bug that, for a while, made me doubt my grasp on the very foundations of Javascript .

Symptom: I am calling a function, getCommonData, loaded from a module called feedScanner. Calling getCommonData() ought to return actual data. It does in unit tests, but, in practice, it’s coming back in its initialised state.

// This fails as it thinks the scanner has not started.

const commonData = getCommonData();
console.debug('commonData', commonData);

Investigation: It looks like my hunch was right, there are two feedScanner modules! WTF.

*** Hey I’m a feedscanner ***
*** Hey I’m a feedscanner ***

Javascript imports are cached so why am I seeing two ditinct feedScanner modules?

Investigation: It must be something to do with thewebpack config. It’s custom and complex in this project.

Weirdly, maybe this was always happening but I’ve only just noticed it now because now is the first time I have been relying on the data. Could that even be true?

Also

I just rewrote how the feedScanner is triggered so it doesn’t start until hears a message (via window.postMessage) that some ‘common’ data has been captured and is ready for use by the feedScanner.

To

Maybe I really don’t understand the Javascript import system, or at least what Babel does with my code and what weird side-effects it might introduce.

Lots of moving parts and lots has changed.

It’s too easy to scapegoat Webpack.

Investigation: More digging. Still blame my Webpack config. Messing about with stuff in my Webpack config like:

optimization: {
 runtimeChunk: ‘single’
}

which is crazy voodoo and promptly gave me four separate feedScanners!

FML.

❄︎ — — — — — — — — — — — — — — — — — — — — ❄︎

I Started to consider stranger theories about why there might be two feedScanners. I rewrote lots of adjacent code. I slept on the problem. I woke up with an idea.

Maybe it wasn’t Webpack.

❄︎ — — — — — — — — — — — — — — — — — — — — ❄︎

The problem

In a nutshell.

There’s no better high than the flood of realisation as you crack a problem. Alas, the come-down is that you get to add to the pile of evidence as to what an idiot you actually are.

In the file receiving empty data:

import { getCommonData } from ‘src/content/feedscanner’;

In all other files that relate to the feedScanner module:

import { start } from ‘src/content/feedScanner’;

Webpack was loading TWO feedScanner modules — but that’s neither a fault of Webpack or of my configuration. It’s something much more prosaic.

The correct spelling should have been ‘feedScanner’ but macOS, being a non-cased file system didn’t notice. But Webpack cares about case, and assumed they were two different modules. It pulled them both from the same file however, so they were the same code, but to Webpack it looked like a different file, and to the resulting Javascript they were two independent modules.

Lesson learned

For the hundreth time: macOS is not a case-sensitive file system, and it’s not always Webpack or your Webpack config that’s to blame.

Remember folks, Sturgeon’s Law applies to yourself as much as anything else.

Thanks for reading.

—

Like this but not a subscriber? You can support the author by joining via davesag.medium.com.