-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
webpack loader #26
Comments
I also run into this issue, so add a +1 here to renaming source files to .jsx. This doesn't only affect react-select, but also to its react-input-autosize dependency. For the time being, you can special-case the library in webpack this way: module.exports = {
// ...other webpack config
module: {
loaders: [
// ...other loaders
{
test: /\.js$/,
include: path.join(__dirname, 'node_modules', 'react-select'),
loader: 'jsx-loader',
},
],
},
}; |
Sorry to take to long to respond to this @yonatanmn and @julen. Would it solve the issue if we added the |
I'm afraid the header doesn't solve the issue, plus it's unnecessary starting from 0.12 (I guess the OP was on React <0.12). As a dev I don't like the idea of processing non-JSX files through the jsx-loader — it's superfluous. Special-casing for a library sucks too (see the workaround described above). As mentioned earlier, the natural solution for me is renaming the source files to .jsx, as these contain JSX code. If they're kept in .js, I'd expect them to be plain React with no JSX syntax. |
@julen I thought maybe Webpack could be configured to process files with the JSX header, even though it's no longer necessary. Sound like that's not a thing. The reason I don't like renaming the files to I appreciate not having to stop and think "oh wait, this is now a different type of file" and renaming it. And sometimes I refactor JSX out of files too - which would then be the opposite. I don't want to call files without JSX In them
Sure, what about ES6 code though? I'm looking at using 6to5 for some projects too, by the same logic I should name a I'm not having a go, I just publish a lot of code across a lot of projects and if I make this change, I'll make it everywhere for consistency and I'm taking the time to think about whether it's the right long-term approach. I can understand you don't like processing non-JSX files with the jsx loader, and I agree the special-casing really does suck. I want this component to be as easy to drop into your project as possible, regardless of your build process or other packages. Hopefully we'll come up with some good answers in #40, and I'll get it cleaned up soon.
The other counter example here would be coffee script files with the |
It's appreciated the time you've taken to think about this and your determination to address the problem generally, so it gets fixed once and for all across your other libs. I believe the angle we're focusing this issue is not completely right for library consumers, although the points you're raising are very valid for the library developers. In the end, users shouldn't care about the file extension or build tool you have chosen when developing the library. As mentioned in #35, there wouldn't be a need for consumers to process react-select through a JSX transform step (or any other transforms such as 6to5). Having said that, I'd close this issue in favor of #35 and #40. Hopefully we can soon offer a solution that works for everyone. |
Agreed. We'll get there. |
|
the files are named *.js and lack the required jsx header,
this is fine when you use reactify, but i'm using webpack and hot loader, what makes them un-readable as js file.
to solve the problem I've changed them to jsx with :"@jsx React.DOM",
Is there any better way?
The text was updated successfully, but these errors were encountered: