-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[2.7.0] Recursive SockJS Errors #1021
Comments
I got a similar problem too. With This is caused by #911 |
Same issue over here 2.7.0 seems to be broken |
Not need for enabling HMR by the way. It doesn't work even without it. |
We're in a pickle because the updates to socksjs passed all of the tests we presently have before it was merged, and it was reviewed. So it wasn't a bug that was willfully introduced. If anyone can create a small example that devs can use to reproduce, that would be immensely helpful. Update: I've run through a slew of the examples with no errors. We're definitely going to need an example app that we can reproduce the errors with. |
+1 (Please don't drop +1 comments on issues. It interrupts the flow of the discussion. Instead, use the reactions button on the original post in this thread to add a 👍) |
@shellscape It's maybe not the simplest example but here's a failing app: https://github.com/jaredlunde/webpack-dev-server-failure-example/tree/master |
@jaredLunde thanks, that at least got us moving forward. I modified your server options in new WebpackDevServer(webpack(config), {
publicPath: config.output.publicPath,
sockjsPrefix: '/assets',
historyApiFallback: {
disableDotRule: true
},
disableHostCheck: true,
quiet: true,
inline: true,
compress: true
}) The two key changes were to |
I confirm the symptoms. If I rollback to the 2.6.1 everything works as expected (without changing anything in my configuration). With the 2.7.0 the generated code looks for
But the file is still served at the root
To fix the issue (keeping the 7.0) I have to add
This is a bit confusing for new comers (since it's not documented yet). Maybe sockjsPrefix should have the publicPath value by default or the previous behaviour should be restored. |
@Grafikart see previous comment. Taking my previous comment a bit further I removed the property for |
Same issue, 2.7.0 was a big breaking change. If this was intended it should have been a 3.0 release, not a minor. |
@contra That's an incorrect statement; 2.7.0 was not a breaking change. It inadvertently introduced a bug that got through several reviewers and tests. "me too" replies aren't helpful, please hold off on those in the repo in the future. At best you're distracting from the discussion around the actual cause of this. |
@shellscape If it wasn't intentional that's fine, you should roll it back (push the last working version as 2.7.1, then deprecate 2.7.0) so when people update their deps they aren't having issues. No need to be rude, I'm not "me too"ing but actually suggesting a temporary fix so people's code doesn't break between now and when the bug is fixed. |
@contra I must disagree; there was no rudeness and "same issue" is essentially "me too." The webpack team is presently discussing the best course of action in the mean time. You're welcome to join the webpack gitter to discuss the logistics further, but I'd like this topic to get back on track to discovery and resolution of the issue at hand. |
@shellscape please let me know how I can help with this. sounds like there are some cases I didn't account for. |
@kellyrmilligan thanks much. Check out @jaredLunde 's example app and how those different options affect the errors in the devtools console. It looks like there's a discrepancy between the actual location of the sockjs-node file and where the client thinks it is. FWIW this only seems to affect apps which set |
@shellscape i have this issue without public path. let child = spawn('webpack-dev-server', ['--config', argv.config, '--progress', '--colors',
'--hot', '--inline', '--port', argv.port,'--history-api-fallback', '--content-base',
'./devdist/', '--host', '0.0.0.0', '--disable-host-check'], {env}); |
@bdwain thanks for sharing that. out of curiosity, when you also set disableDotRule to true, can you reproduce? |
hm that option doesn't seem to be available via the CLI, so i'm not sure i can test it. |
so yes, right now it is assuming that if public path exists, the sockjs shoudl be mounted under that path, hence the option set. should we make it so that if public path is set it and sockjsprefix isn't set that it assumes public path? |
or inject the sock prefix as a variable similar to webpack_public_path so the client can use it? |
@kellyrmilligan right now the sockjs path doesn't know whether or not the option has been set, it assumes that public path is always the prefix. What we really should do is make the entire options object available in some way to future proof against code needing to assume or derive options from other data, and specifically to provide the prefix option to the client. That's what I've been looking into, while continuing to discuss the issue with the webpack folks. I'm open to suggestion as to how to implement that. It looks like we're getting pushback from NPM on unpublishing 2.7.0 so we'll likely issue 2.7.1 to roll back that commit. (+@Timer) That will likely block you on facebook/create-react-app#1887 until we find a solution. |
yeah, fair enough. |
OK 2.7.1 has been published sans the sockjs changes. That should get everyone back to normal while we try and solve the issue. |
I can confirm that it fixed the issue I encountered! |
@shellscape please let me know how I can help get a solution across the line that can encapsulate sockjs. I apologize for not noticing this underlying assumption in my PR. |
@kellyrmilligan no worries, you're definitely not the only one that missed this. We basically need to get to a place where we can pass/inject the WDS config/options into the client bundle. That's the goal I think we need to aim for, then there's no extrapolating options based on other property values. It'll be pretty implicit. |
@rgo that's not the same issue, not even close I'm afraid. yours is likely more similar to #1090. @ all - during work on v3 we've identified a way to use |
@shellscape ops, sorry. Thanks for the pointer 👍 |
@shellscape I'm facing multiple errors which occur on different browsers at run time only (builds fine). Is this the same issue?
|
@nealoke see my previous comment. doesn't look like the same issue. |
@shellscape didn't notice the remark about version 3. Any idea on when this will be released? Or do you recommend using webpack-dev-server@next? |
To summarize it for myself: There are two usecases, right?
Did I summarize correctly and which scenario is currently possible to achieve (with or without options)? |
@Valorize from what I understand, folks want to be able to proxy several apps running webpack dev server locally. currently it will always request |
Coming from another Issue (#1165) that was closed due to this one ... This issue here is quite long and i could not figure if there has any progress been made. I am running an Nginx Reverse Proxy setup and SocketUrl failed me for port reasons. Since i couldn't find any option to deal with this issue, i've simply hacked the value in webpack code itself (which is bad bad and dirty). Can you please add an option for people like me, so the webpack-dev-server can run with port X while SocketUrl runs its requests with a different port? My current SocketUrl code:
Thanks allot for all your effort with this. |
Apologies, what does "waiting on upstream" mean? In this case, what is upstream? I was able to sort of hack around the error but needed to locally patch the webpack-dev-server client code In
Which is where it's being served out of from Server.js Obviously not a great solution since I do want the prefix to still be there I've also tried going the other way and adding my prefix to the line in server.js sockServer.installHandlers(this.listeningApp, {
- prefix: '/sockjs-node'
+ prefix: '/myprefix/sockjs-node'
}); The initial request goes through, but subsequent requests are still sent to the root (
If I go to Update: looks like it's due to live.js always using a hardcoded path to a root
|
I opened a PR that should solve the same problem as #911 while also not result in the same bugs that were reported here |
Looks like the above PR never merged? I'm still seeing this issue. Is there any progress here? Any workarounds that don't involve manually patching webpack? |
We've resorted to forking it Alternatively I heard that webpack-serve might work |
The new PR is here: #1553 |
I think I have a related issue that surfaced with everything newer than |
It appears indeed that downgrading
In order to resolve this I had to downgrade So, this ended up being the winning combination. For now. npm install webpack-dev-server@3.1 webpack-cli@3.1 --save-dev Is |
Hi, I have the same problem, please help me : https://stackoverflow.com/questions/63357106/socksjs-infinite-loop-with-vue-js Forwarded vue.js 8080 dev environnement axios to port 80 with the vue.config.js , cause my python flask server is always running on port 80, waiting for web services calls.
Tried the mikkotikkanen This is what my flask server says .
And what my vue.js console says
EDIT : Hey Guys, resolved with this code , simply write this in your vue.config.js at the root of the vue.js app, so the wrong sockjs-node queries will get ignored, only web services will be forwarded :
Then, do an axios query from vue.js like this :
Then, in ur python or node server , the web service must look like this 👍 |
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Start the dev server with HMR enabled. Here's my dev server configuration:
I start getting the following errors:
Which then cause other errors in the application and seems to recurse back causing to the same set of errors to continually fire.
What is the expected behavior?
No errors. With v2.6.1 of this package everything works fine.
If this is a feature request, what is motivation or use case for changing the behavior?
N/A
Please mention your webpack and Operating System version.
OSX 10.12.5
Webpack 3.5.1
The text was updated successfully, but these errors were encountered: