[2.7.0] Recursive SockJS Errors

[skipjack]

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:

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

[renchap]

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 #911

[robmoorman]

Same issue over here 2.7.0 seems to be broken

[the-spyke]

Not need for enabling HMR by the way. It doesn't work even without it.

[shellscape]

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.

[karolyi]

+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]

@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

[shellscape]

@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.

[Grafikart]

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

http://localhost:8080/{publicPath}/sockjs-node/info?t=1502209431225

But the file is still served at the root

http://localhost:8080/sockjs-node/info?t=1502209431225

To fix the issue (keeping the 7.0) I have to add

sockjsPrefix: '/dist', // My public path without the ending /

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.

[shellscape]

@Grafikart see previous comment.

Taking my previous comment a bit further I removed the property for historyFallbackAPI entirely, and only added the sockjsPrefix property, which resulted in a successful run. I removed the property and things started failing immediately. So it would seem that when publicPath is set, the code is assuming sockjsPrefix has been set.

[yocontra]

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.

[shellscape]

@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.

[yocontra]

@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.

[shellscape]

@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.