Remove Babel dependencies.

[ericelliott]

Remove Babel dependencies.

[ericelliott]

This isn't laziness, just earliness. It's currently in proof-of-concept phase (see status in the docs). I'm open to adding dist builds, with the caveat that the documentation should mention that we use generators, and that the Babel generator runtime will be required for ES5 environments.

[danielkcz]

Laziness is when the user refuses to complete the final 1% of the task :)

If it would be only really just 1%... As I said the main problem is that when you are bundling, you assume that all modules are ready for ES5 environment. This is true for most of the modules. Then one of those modules suddenly decides not to do it it which results in some strange syntax error messages to consumer. No hint or clue what to do about it.

Besides the Babel doesn't make it any easier to selectively transpile node_modules. You have to fiddle with some regular expressions. Because of that I am fairly certain, that I wont be using this module. It just makes things messy.

If @ericelliott really wants this to go through, then I think it should be at least mentioned in docs ideally with explanation how to configure babel to transpile this module.

[zouhir]

Yes node does. And tape should be fine (mocha probably won't). But anyone who wants to run the tests has to be on node 6.x.x.

• I'll remove Babel stuff
• update the readme
• would you like me to echo some pretest message for users on 4.x? Please let me now

[danielkcz]

Hm, doesn't removing Babel means ditching environments that are missing those features? For example whole Internet Explorer brand till IE11 doesn't have these. The android and ios are the same.

[zouhir]

@FredyC You'll import and transpile to ES5 on your end so you get full browser & device support. We not shipping an already built package. Babel is for our tests, and it looks like not needed when on Latest stable (or any > 6.0.0)

[danielkcz]

@zouhir From my experience it's generally very problematic to actually transpile code from node_modules. You generally don't enable babel on that whole folder. If there is some module that is not transpiled, you have to add ugly exceptions to your configuration.

Not even mentioning that some people are rather picky on what babel plugins they use instead of whole presets and just because some module has not transpiled their code, they must add extra plugin because of that.

I must say that this would probably kept me from using library, I like my configs smooth.

In my opinion providing transpiled code is just necessary transitioning step till those other environments are more ready or abandoned.

[zouhir]

@FredyC I get what you saying 👍. Correct usually most packages are being shipped ES5 and you get the 'dist' ready built version.
in our case, this package is for redux, Where users in big percentage using React or similar libraries and have a bundler (browserify or webpack) and a babel-loader or or the browserify equivalent (probably called bablify) so and your module's internal (written by you) or external requirements (from node_modules) will be imported and injected in ES5.

Please let me know or reference me to an example where that didn't work for you so I can manage to prevent doing someone else's mistake.

@ericelliott would appreciate looking at this so I don't give misleading info :)

[danielkcz]

@zouhir I do not understand much what are you saying. It's just pure fact, that transpiling something from node_modules folder is PITA

cloverfield-tools/universal-react-boilerplate#41 (comment)

[danielkcz]

Yes there are some comments as well promoting other way around and transpiling on consumer side, but frankly that's total annoyance, especially since you cannot really know which packages need it.

Question is, do you write a module for people or yourself? Removing babel feels more like laziness from author of the package who doesn't care about broad number of consumers. Given that Redux is used universally server/client side, it's clear that it should support more than just Node 6+.

[zouhir]

Thanks for sending this link across, clearly the author of this module @ericelliott is aware of that conversation as he was involved in that discussion.

The author has mentioned in #4

No build step needed! Compiling for the intended targets is a job for the module users, not for us. We don't know the intended targets, so we don't know the right options to build for. If we give them the raw source, it gives users the flexibility and freedom they need to decide things like whether or not they need to bundle a generator runtime, etc...

Answering your question, Question is, do you write a module for people or yourself?

I didn't write this module, I can't answer on behalf of the author. But I usually write them for myself to serve my purpose, then push them to help people having a similar problem to mine. Removing Babel now will make things bit cleaner, but that might not be final decision. The author was thoughtful not lazy. He shipped a 99% working solution. Laziness is when the user refuses to complete the final 1% of the task :)

I think we need to find a solution all together, I'll wait for @ericelliott to see if he'd consider a compiled version of the code with multiple variations so users can use out of the box.