Syntax error in IE (non ES5 code in package) about page-lifecycle HOT 2 OPEN

Thanks for writing that post - at some point I'll give that a go (I wish I had more time to work on optimizations like this). I like the idea of shipping ES6+ code and giving developers the choice to transpile it or not, but I don't think that should be done by breaking existing conventions. There needs to be some new convention for how to publish modern JS while clearly advertising what language features are used, so that it is clear what needs to be transpiled. I'm not sure if such a convention exists or what that is, but it is not package.module, because that already means ES5 + harmony imports.

The rollup docs and Babel blog make it very clear that the module field is for code that runs in the target environment in all respects except for imports. Basically all popular libraries today follow this convention - so breaking it results in surprising bugs. This library claims to work in IE, but when installed in a typical app with a typical build configuration, it results in a syntax error in IE.

There are a number of workarounds for this issue, but none are ideal:

• applying babel-loader to this package in particular is surprising/inconsistent and adds unnecessary complexity
• remapping imports is also inconsistent/complicated, and can break code analysis tools like eslint and IDEs which are not aware of exotic possibilities for resolving imports
• applying babel-loader to all of node_modules has benefits as you've pointed out, but also disadvantages. Since published code is generally compiled for the target platform already, it has little effect, and since persistent caching is not easy to set up today, it results in very slow builds. If there was a standard way of specifying what language features were used in published libraries, and if persistent caching was easy to set up, this would work well - but unfortunately those prerequisites are not there today.
• importing the ES5 version of this package would also require special treatment because it doesn't have a commonJS or ES6 export. This option would also lead to surprising bugs because without ES6 exports, there is no compile error when importing a name that is not exported. For example, code like import { PageLiiiiifecycle } from 'page-lifecycle'; would compile without errors, and then behave unexpectedly at runtime because PageLiiiiifecycle is undefined.

I think if you want to publish ES6+ code, it should be in a different package.json key (pick your own draft standard and document which one you used). If not, the README should be amended to point out that IE is not supported, or is only supported when transpiling the published code to ES5 (which is not currently the norm).

from page-lifecycle.

That article was written more than two years ago, back when it wasn't really possible for websites to use ES2015+ code in production, but that's not true any more.

Now that it is possible to deploy ES2015+ code in production, it's actually quite problematic to publish packages to npm with ES5 source code—as doing so forces legacy code (often 20-30% larger) on users who are using browsers perfectly capable of running modern JavaScript.

By publishing ES2015+ code to npm, you give web developers the choice between transpiling or not transpiling, which ultimately gives them more freedom and benefits users.

Also not that, while excluding node_modules from babel transpilation may be common, it's not the default. You have to explicitly opt-in to this behavior by adding exclude: /node_modules/ to your babel configuration. The default behavior is to transpile everything (which I recommend).

If you need ES5, this package does distribute an ES5 version of the code, and (if you don't want to update your transpile settings) it's fairly straight-forward to configure webpack to map bare references from page-lifecycle to page-lifecycle/dist/lifecycle.es5.js. You could also configure babel to include page-lifecycle files but exclude all other node modules.

Beyond these options, I'm hesitant to change package.main or package.module to point to an ES5 version because I think it's bad for the ecosystem to promote the idea that ES5 is still required, even though it hasn't been for more than two years.

from page-lifecycle.