IE, Webpack and strict mode

Supporting Internet Explorer is one of those phrases which spoken aloud makes a person bang their head against the nearest hard surface if they’ve been in web development for longer than two weeks. Don’t get me wrong, it used to be much much worse back in the day of IE6 and IE7 and supporting Edge is several orders of magnitude less stress inducing (and Microsoft did a good job of branding Edge to put some distance between Edge and IE).

The most common issues are around wildly different or even completely lacking support of some CSS property, selector or something. I generally don’t expect to encounter problems with JavaScript in IE, so that’s what happened to me last week.

I was checking a cleaned up component of Enectiva in IE to deal with some styling issues just to discover that when a certain JS code path is hit, IE spits out an enigmatic error message and gives up. While the error message contains a code that can be googled, the number of search results is overwhelming and confusing.

I didn’t write down all the steps along the way but the problem was in a piece of code generated by Elm (which hasn’t been a problem before) compilation and a strict mode in JS. The resource which finally pointed me in the right direction (i.e. what might be causing the error instead of figuring out how to turn off the strict mode) was a comment over at a VueJS forum by a user named sqal. It is, however, rather hard to debug in development when using Webpack with hot reloading which loads all the code as a string and evals it as pointed out further in the same discussion. Eventually, it turned out there was a code in Elm which (simplified) reads as:

selectOptionX model newValue =
    { model | optionX = newValue
            , optionY = calculateSomething
            , optionZ = calculateSomethingElse
            , optionY = calculateSomething
            }

There actually was a duplication and while the second assignment to optionY was harmless it lead to JS code assigning the same property of an object twice which IE choked on. IE actually helped to find a chance for a bug to sneak in here. Webpack was a red herring in this scenario.