async-to-gen conflicts with babel about async-to-gen HOT 11 CLOSED

Thanks for the elaboration. We agree on mostly all of it. One problem tho, as stated before: it does not work with babel runtime. I am using another lib called zeit/micro, that uses your lib as is, and breaks my app that relies on babel runtime...so your little piece of code is breaking other code that relies on it, when used in conjunction with babel...not good

On 6 sep. 2016, at 18:45, Lee Byron [email protected] wrote:

I'm honestly confused here. I'm happy to take constructive feedback about how this tool or its documentation could be improved, but it is unclear to me what it is that you're suggesting be done or what you mean by joining forces.

Babel is an awesome tool. You should use it if it solves problems that you have. I use it all the time in my own projects. Babel even has support for async functions!

However just because Babel support exists doesn't mean no other tools should. This tool, async-to-gen, makes intentionally different choices from Babel about how it works. That does not make it objectively better or worse, it just presents an alternative which under some circumstances may be a better fit and under others may be worse.

If you need other features of Babel, like JSX or ES7+, then you should definitely use Babel! It's what I would and do choose for that circumstance. If you're using Babel then you already have config files set up and adding async support is not hard. But if you don't need anything else Babel supports then this tool may be the better choice for you!

Does that mean it conflicts or makes problems for Babel? Or that this module is somehow "rogue" or not playing nice with some philosophy? I wouldn't think so. It's just another available option should it be the right one for your project.

If you do think it is problematic and have clearer feedback about how to improve that, then I would be more than happy to hear it and attempt to improve the tool.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #15 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AA5fKfZ0HufUFx8XEl_Y40D6qACxEhwbks5qnZingaJpZM4J16BE.

from async-to-gen.

Just FYI - I added a change in #16 that I'll be releasing on npm shortly that should allow use of async-node alongside babel/register without clobbering, however you'll still need to configure babel to be aware of the async function syntax.

This will probably fix the issue you reported at vercel/micro#89 - though I haven't actually tested it within that library.

from async-to-gen.

If you need other features of Babel, then you should just use Babel. It has a plugin for supporting async functions.

If you do not need other features of Babel other than support of async functions, then you should use this library. It will perform faster, is simpler, and has cleaner output if you need to distribute the translated code.

from async-to-gen.

I have read the docs, which say the same. You are not answering the above concerns tho.

from async-to-gen.

Could you elaborate on the concerns? I'm not sure what you're proposing be done

from async-to-gen.

I think I have to let go of my hope: that we join forces when the same result is sought.

from async-to-gen.

I'm honestly confused here. I'm happy to take constructive feedback about how this tool or its documentation could be improved, but it is unclear to me what it is that you're suggesting be done or what you mean by joining forces.

Babel is an awesome tool. You should use it if it solves problems that you have. I use it all the time in my own projects. Babel even has support for async functions!

However just because Babel support exists doesn't mean no other tools should. This tool, async-to-gen, makes intentionally different choices from Babel about how it works. That does not make it objectively better or worse, it just presents an alternative which under some circumstances may be a better fit and under others may be worse.

If you need other features of Babel, like JSX or ES7+, then you should definitely use Babel! It's what I would and do choose for that circumstance. If you're using Babel then you already have config files set up and adding async support is not hard. But if you don't need anything else Babel supports then this tool may be the better choice for you!

Does that mean it conflicts or makes problems for Babel? Or that this module is somehow "rogue" or not playing nice with some philosophy? I wouldn't think so. It's just another available option should it be the right one for your project.

If you do think it is problematic and have clearer feedback about how to improve that, then I would be more than happy to hear it and attempt to improve the tool.

from async-to-gen.

I am using another lib called zeit/micro, that uses your lib as is, and breaks my app that relies on babel runtime

Ok I don't think that part was explained as clearly in the first posts. So the issue sounds like another 3rd party lib (https://github.com/zeit/micro) in this case is using async-to-gen but your own code is using babel and it's not working together?

from async-to-gen.

Aha, I understand now, thanks. It seems like the right path forward is for zeit/micro to provide an opt-out of using this library's register for those who are using Babel register already, since as you pointed out, only one node register hook can be used at a time.

I see you've already opened an issue on that library, so hopefully progress can be made there

from async-to-gen.

Yes. I already managed to work around the shortcoming. Thanks for thinking along :)

from async-to-gen.

Wow, great work :)

On 7 sep. 2016, at 19:18, Lee Byron [email protected] wrote:

Just FYI - I added a change in #16 #16 that I'll be releasing on npm shortly that should allow use of async-node alongside babel/register without clobbering, however you'll still need to configure babel to be aware of the async function syntax.

This will probably fix the issue you reported at vercel/micro#89 vercel/micro#89 - though I haven't actually tested it within that library.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub #15 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AA5fKfUtdtLhvXu6jJo0Y74KntD7q0QBks5qnvH8gaJpZM4J16BE.

from async-to-gen.