Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support more extensions in register hook #12

Closed
rattrayalex opened this issue Aug 31, 2016 · 2 comments
Closed

Support more extensions in register hook #12

rattrayalex opened this issue Aug 31, 2016 · 2 comments

Comments

@rattrayalex
Copy link

I imagine many users may wish to use this with .jsx files, and possibly also with .es6 or similar files.

Of course, they can always do this with a method other than the register hook. But it might be surprising that it won't work with jsx files.

It might also be worth documenting that in order for jsx to be processed, you would need to do something like this:

require('async-to-gen/register')
require('babel/register')

with async-to-gen coming first. (see also #11)

@Morriz
Copy link

Morriz commented Sep 6, 2016

I created a pull request with a fix that would not register async-to-gen when another hook is active, allowing a previous hook (babel etc) to be leading: #14

Maybe not the nicest of fixes, but after spending 2 hours on a solution I settled for that, as it just covers most use cases.

@leebyron
Copy link
Owner

leebyron commented Sep 7, 2016

I've changed the behavior of the register hook in #16 to apply to any compiled module rather than using require.extensions. This abstracts it away from the file extension so that it will just use whatever behavior node already uses. That means implicit support for .jsx and .es6 or .omgwtf if that's what you're into.

#16 also ensures this module's require hook doesn't clobber an existing one like Babel's, however the only way to accomplish that is by going second. Babel's transformer will run first. If you're already using Babel to handle JSX, then you're best off just handling async functions within Babel as well (use babel-preset-es2017) and probably just don't use this library at all. However this also means if you're using async-node by accident or otherwise that things won't break.

@leebyron leebyron closed this as completed Sep 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants