Luxon: Which builds should be polyfilled?

[icambron]

One problem around here is that I have no idea how people build modern Javascript applications. Luxon uses a few things not available in IE. You can see them polyfilled here. Luxon's build toolchain can decide whether it wants to include that stuff or not on a per-target basis. It's fairly obvious that for the browser global build, I want that stuff in there, and for the ES6 build I don't. But what about the CJS and AMD builds? In particularly, the CJS one goes on NPM and gets consumed by other people's toolchains. Do consumers of that expect libraries like Luxon to have polyfilled themselves or would they rather the libraries be smaller and add their own fills where needed?

[icambron]

I wonder if @ovangle knows the answer to this

[azu]

Maybe, Polyfills and the evolution of the Web is a helpful source.

1. Advice for library and framework authors
   5.1 Consider whether to include polyfills
   -- https://w3ctag.github.io/polyfills/#advice-for-library-and-framework-authors

[icambron]

Thanks, there's some helpful pointers in there for sure. I may modify some of my approach.

[teppeis]

@icambron Which Node version is supported?

Don't bundle pollyfill to CJS package because globals should not be modified and there is no code using "runtime" features not supported by Node v4.

But "syntax" features not supported by Node v4 are used (such as destructuring, spread operators and rest/default params).
It needs babel to transpile if you support it.

FYI: eslint-plugin-node:no-unsupported-features is very useful to detect them.

[icambron]

@teppeis I haven't figured out what the minimum Node version supported is, but I'll probably just go with the minimum version of Node supported generally. I currently am conditionally modifying globals here in the CJS build; I'm not sure which ones are supported already in what versions of Node. The CJS code is already compiled to ES5 by Babel, so my only concern is "runtime" stuff. I should probably use the /library versions of the CoreJS fills, but that makes it much harder to make an optional fill-free build.

I'm not sure it's as simple as finding out what minimum version of Node to support, though. Don't most Webpack users load their dependencies through NPM? They'll be using the CJS build too and that's where this seems more complicated.

[tinovyatkin]

You definitely should switch from babel es2015 preset to babel-preset-env and let it manage polyfills and transpilling for node, targetting probably Node 6.x (previous LTS).

[icambron]

I should definitely switch the env thing, yeah.

Node 6 is way ahead of IE 11, though. So if someone is using Webpack and loading Luxon through NPM, they wouldn't get the polyfill and nothing would work. So I'm still wondering if the best practice for Webpack users is to tell them to do the fill themselves?

[tinovyatkin]

There is a browser field in package.json designed for that use case. And Rollup also has a field for ES6 version, so, webpack probably have too.

[tinovyatkin]

On side note, I'm personally hates to see library authors polyfilling basic things because it bloats with duplicated code and also may change globals. I do appreciate Choice.js approach - he just lists all features that may be need to be polyfilled together with suggestion to use polyfill.io. Releasing new JS library in 2018 with half of the code volume being polyfills for IE9 seems like an overkill for me.

Polyfilling should be an developer decision in base of their target audience.

[icambron]

I agree in principle. In practice it really sucks when everyone complains that your library throws errors when they use it. Edit: I'm open the suggestion that developers who use Webpack are more likely to do this anyway!

[icambron]

Also, the joke is on me, as per usual: because of a bug in the gulpfile, I haven't been including the polyfills anyway. IE is totally broken and no one has complained. Rather than fix it I think I'll just do the work of sorting all this out.

[icambron]

@tinovyatkin I ended up taking most your suggestions in #95.

[icambron]

Fixed in #95.