The Bug I Spent 3 Days Debugging Was Just a Variable Name Typo
The logic was obviously correct, but the value wasn't coming through in certain cases. I added logs, set breakpoints, and dug through the library docs, but couldn't find the answer.
What I finally found this afternoon was that I'd written userId as uesrId, and because of exception handling, that line was silently passing through as undefined. It didn't throw an error, so of course I couldn't find it.
It was a day that made me resolve to run my lint settings a bit stricter. What lint rules are you all using?
7 answers
Is there a source? How is lint supposed to catch typos like uesrId? If it's an undeclared variable, no-undef catches it, and that's already the default anyway...
Ah, this is a total unspoken rule... I went through something similar, and since then I can't code without lint.
Keep ESLint's no-undef and no-unused-vars enabled by default, and if you're using TypeScript, noUncheckedIndexedAccess is recommended too. With it enabled, undefined access is caught at the compile stage, so silent failures caused by typos are almost always caught.
Well, I don’t know about that. Isn’t the real culprit the code that quietly lets exceptions slip by? Blaming the linter seems like a bit much lol
100% agree. For me, it started with console.log hell before that.
Lint is good too, but when I’m looking for that kind of thing, I tend to start with git diff or blame. There’s a high chance it’s somewhere that was touched recently. And catch blocks that silently pass undefined are really dangerous, so I recommend changing them to at least log something.
Isn't this an old story? These days, if your editor has a type checker, a red line appears the moment you use uesrId.