hard-source-webpack-plugin
hard-source-webpack-plugin copied to clipboard
Incompatible with `react-svg-loader`?
Hi! First off, thanks for a great plugin!
When I added it to our React/TypeScript project I got errors on our imports of svg files. The error was this:
Module parse failed: C:\path\node_modules\react-svg-loader\lib\loader.js!C:\path\src\Icon\glyphs\ic_exit_to_app_24px.svg Unexpected token (4:11)
You may need an appropriate loader to handle this file type.
As you can see we're using react-svg-loader to turn a pure svg file into a React component. I read in some other issue here that all plugins/loaders aren't supported (which is reasonable). Is this why we're getting the error? Is there any other info I could provide that would be helpful?
If the issue here is that react-svg-loader is incompatible with hard-source-webpack-plugin then what makes it incompatible? Perhaps I could open a PR to react-svg-loader.
@andersekdahl I assume you are referring to issue #72. That issue is just listing all the webpack first-party plugins and loaders and making sure hard-source has tests for all of them. Many tests have yet to be written but that doesn't explicitly mean that those plugins and loaders will not work. Most loaders should just work and many plugins as well.
In regards to react-svg-loader can you make a minimal repo on github that creates this error? That'd help me a lot in making a regression test and any needed fixes.
I took a look at the loader and nothing stands out to me as something that would fail with hard-source. So it'll be up to a failing minimal repo to figure it out.
By the way thank you for opening this issue.
This error is a little odd in regards to hard-source. Normally you wouldn't get that error from hard-source as it caches an already built module and doesn't pass it back through the same process. It shouldn't have the opportunity to create that error. I could totally be overlooking something as well. Hmm.
Having fixed #149, I think this relates to a similar issue. hard-source-webpack-plugin also caches how most modules and their loaders are resolved. The loaders list probably isn't being thaw'd correctly leaving webpack to build a module without the loader.