question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Module file contains ES6 syntax that breaks in IE11

See original GitHub issue

When importing AutoNumeric in conjunction with a module bundler with the import syntax, like so

import AutoNumeric from 'autonumeric'

The file that ends up being imported is the one specified by main in package.json. In this case, it’s dist/autoNumeric.js. That file, however, contains ES6 syntax not supported by IE11 (notably, the arrow function =>).

Most people choose to not run Babel on node_modules contents as this severely slows down builds and can even cause problems. As such, it has become common practice to transpile to ES5 compatible code the module file that will be included. One such discussion on StackOverflow.

An alternate solution in the meantime is to instead do:

import AutoNumeric from 'autonumeric/dist/autoNumeric.min';

To import the minified version which seems to be generated using only ES5 code.

I’m using the latest AutoNumeric version, 4.4.0.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:8 (8 by maintainers)

github_iconTop GitHub Comments

2reactions
alexturpincommented, Sep 12, 2018

I did some more digging, and I apologize, it turns out I was 100% wrong about pretty much everything I said.

Files in dist are in fact all ES5. I was however actually getting ES6 AutoNumeric files in my bundle. That’s due to Webpack’s resolve.mainFields defaulting to ['browser', 'module', 'main']. AutoNumeric has no browser field but it does have a module one, which correctly points to the original ES6 code. I changed my mainFields config to instead be ['browser', 'main'] and all my problems are solved.

I would make the recommendation that browser be used instead of main. As per npm’s browser docs:

If your module is meant to be used client-side the browser field should be used instead of the main field. This is helpful to hint users that it might rely on primitives that aren’t available in Node.js modules. (e.g. window)

Thanks again for your help and sorry for the false alarm!

0reactions
alexturpincommented, Sep 13, 2018

Awesome, thank you @AlexandreBonneau

Read more comments on GitHub >

github_iconTop Results From Across the Web

IE11 JavaScript Syntax Error on class, built with Webpack
JavaScript compiles just fine, it works fine in modern browsers but it still leaves class definitions in ES6 form which breaks the IE11....
Read more >
import - JavaScript - MDN Web Docs - Mozilla
This is often a relative or absolute URL to the .js file containing the module. In Node, extension-less imports often refer to packages...
Read more >
Dropping Support For IE11 Is Progressive Enhancement
Because this code is essentially set in stone, I don't have to worry about new JavaScript features subtly breaking IE11 behind my back....
Read more >
To v5 from v4 - webpack
This guide aims to help you migrating to webpack 5 when using webpack directly. If you are using a higher level tool to...
Read more >
IE11 and the Missing Polyfills - DEV Community ‍ ‍
-> · you don't have to ship polyfills to a browser which supports these features. · you don't have to ship a polyfill...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found