3 ms·
There's one non-obvious corollary from the fact that using let/const before declaring throws an error and var does not: If you have let/const in your source co
by jakub_g 7y ago
There's one non-obvious corollary from the fact that using let/const before declaring throws an error and var does not:
If you have let/const in your source code, but you use babel to transform it to ES5, you may have cases where you use let/const in that error-throwing way, but it's compiled down to var, and all is good (apart from variable being undefined when used).
When you however upgrade your babel conf to output ES6 and not compile down to var, you'll be having reference errors in those places, which may explode your app. I learned in production after enabling "differential serving" (module/nomodule).
There's an eslint plugin that can check for this stuff, but it finds false positives in 95% of cases (matter of personal preference - it disallows "valid but not blessed by the authors" behavior), so it's very likely you don't have it enabled, just like us.
- _bxg1 7y agoOof. I was surprised for a second that Babel would simply put "var" in there instead, when it expressly doesn't do the same thing. But then I realized that emulating block scope without let would mean wrapping all blocks in anonymous functions, which would carry significant overhead. Gross.
- thewarrior 7y agoSo transpiling down to ES5 doesn’t preserve semantics ?
- jakub_g 7y agoFor some features, having 100% spec compliant behavior in transpiled code would mean excruciatingly slow/bloated code, or be downright impossible. There's a reason why features are added to the language after all: to add things that are impossible or too complex to write in old version of language. Transpilation is "best effort" and involves some tradeoffs.