Dist files contain eval

Currently, the browser field (and maybe the main field depending on #609) point to dist/autoNumeric.js, which is a bundle that uses a bunch of eval function calls to make the code work.

I wasn’t able to find anything definitive on this but I think libraries shouldn’t be distributed using eval. The only real evidence I have of my claim is that out of all the libraries my app uses, AutoNumeric is the only one that ends up with eval in my bundle.

However, it also causes a real observable issue: the eval code is full of comments and whitespace, and those are not able to be stripped out by minifying build processes since they are in an eval call where the code is just strings.

An easy solution is to simply make it point to the dist/autoNumeric.min.js file instead.

Another, arguably better solution, would be for me to simply let my Webpack build process use the module attribute (see #604), as described in Webpack’s Authoring Libraries article:

The module property should point to a script that utilizes ES2015 module syntax but no other syntax features that aren’t yet supported by browsers or node. This enables webpack to parse the module syntax itself, allowing for lighter bundles via tree shaking if users are only consuming certain parts of the library.

However, since this file uses ES6 syntax not correctly handled by browsers I need to support, I would have to complicate my build process to transpile AutoNumeric as an exception inside node_modules. There might be a way for AutoNumeric to provide a file that transpiles everything but module syntax to ES5 but I haven’t found such a way in my quick search.

All in all I am not sure of what the right solution is, I’m still relatively new to the world of webpack, but I wanted to raise the issue nonetheless.

[AlexandreBonneau]

This is live in v4.5.0

[alexturpin]

Wonderful!

When using the library directly in the browser, users should not include the 1.5MB dist/autoNumeric.js file; the 190kB minified version – or even better, the 40kB compressed minified version – are preferred.

In this case, I would argue that browser in package.json should point to the minified (uncompressed) version.