-
Notifications
You must be signed in to change notification settings - Fork 801
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
Fix Babel plugin usage in an external toolkit by hard-coding react-stand-in constant #807
Comments
Not sure I understand the problem, but it is clear how to solve it. |
I've tried to solve this issue by using preval, but it could not import react-stand-in, as long it gonna to be build after the react-hot-loader. So - just hardcoding constant and adding a test to secure the name. |
Nice, thank you! |
@insin - beta 16 just got released. Please check that it fulfils your requirements. |
It works beautifully, thanks: I can now externalise all the react-hot-loader config I need, so I don't need to install development-only dependencies in my app, or runtime dependencies in my development config 👍 |
But you have to entangle your application's code with our, like |
No, I use react-hot-loader-loader to add the The react-hot-loader dependency is managed by nwb, so with this change in place I can now point to the absolute path to the |
Wow, and then magic happens. |
REGENERATE_METHOD
is currently imported fromreact-stand-in
This makes it difficult to extract use of
react-hot-loader
in your development setup to an external toolkit module, as you can't alias the modules imported by a Babel plugin andreact-stand-in
importsreact
.Hard-coding this constant instead makes it possible to use the Babel plugin for this use-case:
Do you have any objections to hard-coding this constant instead?
The text was updated successfully, but these errors were encountered: