-
Notifications
You must be signed in to change notification settings - Fork 272
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
Detecting webpack version via require-ing it works wrong in some tricky cases #338
Detecting webpack version via require-ing it works wrong in some tricky cases #338
Comments
Fixed in |
This change breaks gatsby-plugin-svg-sprite. It works until v4.1.3 Gatsby allows to override webpack config to add loaders such as this one. Although after your change in 4.1.4, the same line breaks with the error |
Hello, The same error |
Getting the same error as @DanielaValero in VS Code while running ESLint with a webpack resolver. |
Hi @DanielaValero , Please how did you downgrade to 4.1.3, because I cannot find svg-sprite-loader in my package.json I have gatsby project |
Same error as @DanielaValero . Currently using |
Yup, the VS Code error unfortunately persist in 4.2.1 which includes #352. |
Actually that downgrading thing did not really work... I still have the problem, it has been so long that when is fixed I will miss the false negatives from the lintin notifications panel in VS Code, and the import statements... |
@agigox @Klutch27 @martinkadlec0 @DanielaValero Using autodetecting webpack version was very bad idea. I've published alpha version without detecting webpack version, could some of you guys help me with trying it out?
|
- use package svg-sprite-loader@drop-webpack-version-detector because of JetBrains/svg-sprite-loader#338
Published |
It's a bug relates to #248.
Here svg-sprite-loader tries to detect webpack version by require-ing it:
https://github.com/kisenka/svg-sprite-loader/blob/master/lib/utils/get-webpack-version.js#L2
But this doesn't work if by some reason we have different webpack versions. I think it'd most reliable to analyze current webpack instance instead which loader is running on top.
The text was updated successfully, but these errors were encountered: