Warn on JSX file extension with check-filename-webpack-plugin #361
Conversation
…into tizmagik-master # Conflicts: # config/webpack.config.dev.js # package.json
ghost
added
the
|
Sorry for the churn, can you rebase please? |
…react-app * 'master' of https://github.com/facebookincubator/create-react-app: 0.3.0-alpha Update some deps Document configuration and build process (facebook#362) # Conflicts: # config/webpack.config.dev.js
|
No worries, it's all synced up now, should be good. Let me know if any of the copy in the comments or the error message needs any massaging. Thanks! |
| // Warn on using .jsx files, prefer using .js only. | ||
| // See https://github.com/facebookincubator/create-react-app/issues/290 | ||
| new CheckFilenamePlugin({ | ||
| regex: /\.jsx$/, |
There was a problem hiding this comment.
Instead of creating a plugin that can be also solved by a loader (which reuses webpack configuration API):
{
test: /\.jsx$/,
loader: 'abort',
query: {
message: '[resource]: .jsx extensions are not allowed, use .js extension.'
}
}
There was a problem hiding this comment.
Is this an actual loader or do you propose to create one?
There was a problem hiding this comment.
That's a good idea, too. @gaearon please advise.
There was a problem hiding this comment.
The reasoning behind choosing loader vs. plugin:
- Loader can reuse path matching logic.
- Loader functional scope is more restrictive: you see exactly what it affects vs. plugin which can do literally anything under the hood. I'd expect the less custom plugins the better, especially when you eject and start modifying config.
There was a problem hiding this comment.
Agreed. I think a loader is the more technically correct solution.
|
Closing now because we support JSX extension since 0.4.1 even though we don’t recommend it. Thanks for sticking with us 😄 |
Fixes #290