Closed yura999999999 closed 3 years ago
@yura999999999 It's a bug caused by merged PR with webpack 5 support
Is there a known way forward to fix this, or is further investigation required? This requires pinning to 5.0 otherwise it breaks linters. Thank you for any communication.
Having the same issue here. It's even blocking the full eslint checkup by the VS Code eslint extension on the project so it's even causing Eslint to not resolve paths.
Is there a known way forward to fix this, or is further investigation required? This requires pinning to 5.0 otherwise it breaks linters. Thank you for any communication.
A quick workaround in your project is to go to the file node_modules/svg-sprite-loader/lib/utils/get-webpack-version.js
and change the const webpackVersion
to a hardcoded string of your webpackversion, like so:
const webpackVersion = "4.44.2";
Could this please get some love and be fixed? As this issue is even stopping the full eslint vs code extension / process here. Thanks in advance!
We have this same issue, but it seems to happen when we go from v5.0.0 -> v5.1.1 or v5.2.1. We are still on webpack v4.44.2
We've had to downgrade this dep back to v5.0.0
Hey folks, could you please provide a repo with a working example of this issue?
Hey folks, could you please provide a repo with a working example of this issue?
I don't believe that's really necesary as it was fixed before by not sniffing the webpack version, but using feature detection. The current version obviously does sniff the webpak version instead again. So guess the solution is in the mentioned commit or the one before that. Please take a look at the references in the 'opening post'.
@Friksel current version use webpack ver detection for correct work with webpack 5. I need an example of the issue to be sure that after the fix it will work correctly.
The problem is the inclusion of the getWebpackVersion from utils. That function is bad as it overwrites require.main property. This causes problems in different engines (like vs code). Feature detection should be used instead of this method. At a minimum, require.main shouldn't be getting toyed with.
I wrote about it earlier in this issue: https://github.com/JetBrains/svg-sprite-loader/issues/381
I start having this problem updating to the latest version 10.0.6
of Next.js.
Without the loader everything works fine so hopefully a fix and solution can be added soon.
https://github.com/vercel/next.js/issues/21789 https://github.com/vercel/next.js/issues/21679#issuecomment-771941447
We've had to downgrade this dep back to v5.0.0
I've also downgraded all projects to 5.0.0 now, which is the last version that doesn't have this issue (The issue started when making the plugin 'ready for Webpack 5' in 5.1.1) Having to change that function everytime we update node_modules is a pain.
I'm working on a fix, please try svg-sprite-loader@5.2.1-remove-get-webpack-version
Also, it would be great if someone checks PR: https://github.com/JetBrains/svg-sprite-loader/pull/440
I'm working on a fix, please try svg-sprite-loader@5.2.1-remove-get-webpack-version
Just did a quick check with 5.2.1-remove-get-webpack-version
and the issue seems gone. Didn't do much testing and didn't check all svg-sprite-loader features though, but the problems getWebpackVersion was causing here aren't there anymore and Webpack doesn't complain using the loader and plugin for creating sprites on a projecct here.
Thanks!
fix released in svg-sprite-loader@6.0.0
Hi there,
After upgrade version to 5.0.0 (commit https://github.com/JetBrains/svg-sprite-loader/commit/b34b2b2ea168a88b451dd3726344fee037cc946c)
Problems with getWebpackVersion returned https://github.com/JetBrains/svg-sprite-loader/issues/338 https://github.com/JetBrains/svg-sprite-loader/issues/309
Previously was fixed by https://github.com/JetBrains/svg-sprite-loader/commit/7131578
@d3x42 Any solutions? is it a bug?