Need help; __webpack_hmr is serving the SPA app

[ghost]

I'm getting this error:

EventSource's response has a MIME type ("text/html") that is not "text/event-stream". Aborting the connection.

The problem seems to be because __webpack_hmr is serving the SPA app instead of the EventSource, but I'm not sure how to fix this.

My Startup file looks like this:

            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
                if (context.Configuration.EnableDevelopmentWebInterface) {
                    app.UseWebpackDevMiddleware(new WebpackDevMiddlewareOptions
                    {
                        HotModuleReplacement = true,
                        ProjectPath = ClientAppPath,
                        ConfigFile = $"{ClientAppPath}build/webpack.dev.conf.js"
                    });
                }
            }
            else
            {
                app.UseExceptionHandler("/Home/Error");
            }

            // add wwwroot/
            app.UseStaticFiles();

            // set up Nancy OWIN hosting
            app.UseOwin(x => x.UseNancy(options =>
            {
                options.PassThroughWhenStatusCodesAre(
                    HttpStatusCode.NotFound,
                    HttpStatusCode.InternalServerError
                );
                options.Bootstrapper = new SpeercsBootstrapper(context);
            }));

            // set up MVC fallback
            app.UseMvc(routes =>
            {
                routes.MapRoute(
                    name: "default",
                    template: "{controller=Home}/{action=Index}/{id?}");

                routes.MapSpaFallbackRoute(
                    name: "spa-fallback",
                    defaults: new { controller = "Home", action = "Index" });
            });

and my Webpack config:

module.exports = {
  entry: {
    app: './src/main.js'
  },
  output: {
    path: config.build.assetsRoot,
    filename: '[name].js',
    publicPath: process.env.NODE_ENV === 'production'
      ? config.build.assetsPublicPath
      : config.dev.assetsPublicPath
  },
  resolve: {
    extensions: ['.js', '.vue', '.json'],
    alias: {
      'vue$': 'vue/dist/vue.esm.js',
      '@': resolve('src')
    }
  },
  module: {
    rules: [
      {
        test: /\.(js|vue)$/,
        loader: 'eslint-loader',
        enforce: 'pre',
        include: [resolve('src'), resolve('test')],
        options: {
          formatter: require('eslint-friendly-formatter')
        }
      },
      {
        test: /\.vue$/,
        loader: 'vue-loader',
        options: vueLoaderConfig
      },
      {
        test: /\.js$/,
        loader: 'babel-loader',
        include: [resolve('src'), resolve('test')]
      },
      {
        test: /\.styl$/,
        loader: ['style-loader', 'css-loader', 'stylus-loader']
      },
      {
        test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
        loader: 'url-loader',
        options: {
          limit: 10000,
          name: utils.assetsPath('img/[name].[hash:7].[ext]')
        }
      },
      {
        test: /\.(woff2?|eot|ttf|otf)(\?.*)?$/,
        loader: 'url-loader',
        options: {
          limit: 10000,
          name: utils.assetsPath('fonts/[name].[hash:7].[ext]')
        }
      }
    ]
  }
}

[SteveSandersonMS]

Unfortunately this is not something I can diagnose given the info here and your custom project setup. I don't know what effect the Nancy middleware might have, for example, or about what publicPath values you're using, what PathBase values are in effect, and so on. Can you compare against the project produced by dotnet new vue to establish which of your differences is making this not work?

Sorry that's not incredibly useful. The ideal thing would be if you could use a debugger to step into the SpaServices code to see where it sets up the listener for __webpack_hmr and find out if it's listening on some other path, for example. However I'm not sure there's a convenient way to do that besides cloning the whole of this repo and connecting your app to it as a <ProjectReference> instead of a <PackageReference>. If it comes to it, that might be your best bet to find out what's going on!