Object.assign and cross-browser compatibility

[ziir]

o/ @pauldijou

I was wondering if you would consider adding a new babel plugin to transform Object.assign to a inline helper,
as it's an es2015 feature and the browser support, though ~correct, is not wide enough to be safely used in production.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign#Browser_compatibility

We've been dodging this issue by patching globals so far, but we'd like to move away from that.

More than happy to open a PR to make use of transform-object-assign, or discuss this further :)

Thank you for your time,

[pauldijou]

Hey @ziir ,

That's a good point. To be honest, I was more thinking about removing babel than adding more plugins. That's because if each lib convert its own source code using babel, all polyfills and boilerplate might be duplicated again and again. There is also the question of how many plugins to add. Arrow functions are still not supported on Edge, should I also add a plugin for those?

What would be best is for libs to follow the standard without any hack and it's up to the users to apply babel or any other solution to their whole source code in order to support whatever browser target they have. I haven't done it so far because I understand that compiling libs on top of your own source code increase build time and is not such a good developer experience.

[ziir]

Well, If one is concerned about duplicating a few (light) inline helpers, one could set babel-transform-runtime as a devDependency and babel-runtime as a peerDependency. Though one could argue that it's not such a good developer experience either (but it's the process we use for all our internal libs).
https://babeljs.io/docs/plugins/transform-runtime/

Arrow functions are already handled by redux-act current babel setup, and the question of "how many plugins to add" that you're referring to sounds more like a reflexion about the lib's browser support target to me.

While I cannot object to the wish of having a library strictly shipping up-to-latest-standard(ish) code, I believe shipping a few babeled inline-helpers with redux-act for ES6+ features really is fine.
Users having stronger browser-support requirements are responsible for dealing with these on their own.

[dtschust]

👍
FWIW I also got bit by this in production yesterday.

I understand your point @pauldijou regarding removing babel and leaving it up to consumers of your library to ensure browser support, but it's a really easy thing to miss when you add a very small library to your dependencies and don't think to test in IE11.

To be explicit: it's completely my fault that I broke my own stuff in production and not at all on you, and I really like using this library so thanks for making and sharing it! We've since fixed this issue on our end, but it might be chill to reconsider adding a polyfill while you still have babel in your build process. Also I believe the babel plugin is a true polyfill in that it doesn't overwrite any native object.assign support if it exists already.

[pauldijou]

Done in 1.2.0

[ziir]

Awesome, thank you very much @pauldijou