webpack loader about react-select

[julen]

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',
      },
    ],
  },
};

[JedWatson]

Sorry to take to long to respond to this @yonatanmn and @julen.

Would it solve the issue if we added the /* @jsx React.DOM */ header back in?

[julen]

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.

[JedWatson]

@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 .jsx is that I don't start files thinking about whether or not I'll use JSX in them, I just use it where it makes the code I'm writing clearer. I think about it the same way I decide between using array.forEach vs. a for (...) loop.

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 .jsx and it doesn't seem clean to have half the logic of an app in files that have different extensions, when it's really the same language*, and it's all going through a single build process anyway (either via webpack or browserify).

If they're kept in .js, I'd expect them to be plain React with no JSX syntax.

Sure, what about ES6 code though? I'm looking at using 6to5 for some projects too, by the same logic I should name a .js file differently if I was using ES6 features that needed transpiling.

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.

* I've considered the similarity between this and naming template files with their language (e.g. .hbs) when they're primarily HTML; however in that case, you're processing one language (handlebars) to generate another (HTML) which is interpreted very differently, so they're actually distinct. In the case of JSX it's really just a different syntax; you're still writing Javascript and it's still executed once as javascript - it just needs to be expanded first.

The other counter example here would be coffee script files with the .coffee extension, which are executed as Javascript, however those files are a completely different syntax, and you aren't just interspersing a shorthand syntax in what is primarily just Javascript.

[julen]

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.

[JedWatson]

In the end, users shouldn't care about the file extension or build tool you have chosen when developing the library.

Agreed. We'll get there.

[JedWatson]

lib files no longer contain JSX and the src files are only referred to in the build process, so this issue is fixed now.