webpack-dev-server: [2.7.0] Recursive SockJS Errors

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:

    devServer: {
        hot: true,
        port:8084,
        inline: true,
        compress: true,
        historyApiFallback: true,
        contentBase: 'dist/',
        overlay: {
            errors: true,
            warnings: true
        }
    }

I start getting the following errors:

image

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

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 34
  • Comments: 51 (24 by maintainers)

Commits related to this issue

Most upvoted comments

Clarification: I receive the infinite loop of xhr, xhr_streaming and eventsource when using webpack-dev-server with https. It only triggers after a manual browser refresh (causing a sockjs disconnect?), after that i’m in the infinite loop och doing xhr_streaming and eventsource GET/POSTs and Node starts consuming about 40%.

Dropping the HTTPS flag makes it work, but is not acceptable for us. Tested with 2.8.2, 2.7.1 and 2.6.1 - same behavior on all of them.

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.

@valorize from what I understand, folks want to be able to proxy several apps running webpack dev server locally. currently it will always request /sockjs-node, and if it is an app under the root, /subpath, then the desired behavior is to have it request /subpath/sockjs-node. I thought in v3 the team is just using native websockets, so I am guessing it may be different.

To summarize it for myself: There are two usecases, right?

  1. You start Webdevserver at localhost:xxxx and have set your publicpath to yyyy. Desired behavior: serve at locahost:xxxx/sockjs-node/
  2. You use a proxy server which redirects path www.zzzz.com/yyyy to localhost:xxxx/ Desired behavior: serve at www.zzzz.com/yyyy/sockjs-node so in fact localhost:xxxx/sockjs-node/

Did I summarize correctly and which scenario is currently possible to achieve (with or without options)?

It appears indeed that downgrading webpack-dev-server to 3.1 resolves this issue, however it appears that webpack-cli has removed something between versions that breaks the whole setup

Error: Cannot find module 'webpack-cli/bin/config-yargs'

In order to resolve this I had to downgrade webpack-cli to matching minor version.

So, this ended up being the winning combination. For now.

npm install webpack-dev-server@3.1 webpack-cli@3.1 --save-dev

Is webpack-dev-server really relying on some specific file in webpack-cli (aka another project) to be available?

I think I have a related issue that surfaced with everything newer than webpack-dev-server@3.1.14. I am getting infinite loops with SockJS errors with all versions past 3.3.0 and browser console warnings in 2.2.0 and 2.2.1 versions. Downgrading fixed everything immediately. I am not using HTTPS with localhost.

I opened a PR that should solve the same problem as https://github.com/webpack/webpack-dev-server/pull/911 while also not result in the same bugs that were reported here

+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 👍)

@jaredlunde thanks, that at least got us moving forward. I modified your server options in server.js and was able to stem the tide of websocket errors:

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 historyFallbackAPI and socksjsPrefix. I’m not sure if folks were overzealous in pushing this forward given this comment, but it appears some incompatibility when historyFallbackAPI is set to true does in fact exist. We could put some logical checks in there to account for the scenarios and force some default values, but I’m open to suggestion from the community.

We’ve resorted to forking it https://github.com/SMARTeacher/webpack-dev-server

Alternatively I heard that webpack-serve might work

@nealoke see my previous comment. doesn’t look like the same issue.

@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 DefinePlugin to inject the devserver options into the bundles. It’s gonna be tricky to back-port that into master given how different the two branches have become, but it’s safe to say that a fix will be available in the near future.

I receive this on 2.7.1 (and 2.8.2 and 2.6.1). Believe it got introduced with us adding https. Any known workarounds?

@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

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.

I got a similar problem too.

With publicPath: 'http://localhost:8080/packs/' HMR is trying to load http://localhost:8080/packs/sockjs-node/info?t=1502201588847 which returns a 404 error. `http://localhost:8080/sockjs-node/info?t=1502201588847 returns the expected value.

This is caused by https://github.com/webpack/webpack-dev-server/pull/911