Webpack dev server does not serve any assets

[juanca]

Environment details:

Most of our workstations are on node 6.3.0 and 6.5.0. And npm 3.10.3.

Issue

Seems like a recent change in our npm-shrinkwrap.json broke the webpack-dev-server (seems like the server cannot find / server any bundle).

We were able to figure out that bumping webpack-dev-middleware from 1.6.1 to 1.8.1 bricks the dev server. While pinning down the middle to 1.6.1 unbricks the server.

Is it normal to specify the webpack-dev-middleware dev dependency in our package.json? Should we try to avoid it to avoid any future headaches?
Is this a known issue and is there an official fix?
Any help would be much appreciated.

Apologies if this is not the right channel to report this. I would appreciate a re-route / suggestions.

[SpaceK33z]

Using npm-shrinkwrap is fine. You've not provided any info as to what your problem is, but at the moment there are no big known issues in webpack-dev-middleware. Could you expand on this? Be sure to include the webpack config, and how you run the dev-server. If your project is open-source, referring to the repo is also fine.

[juanca]

Here's a more detailed breakdown (can elaborate):

Broken state:

A recent PR merge bumped our webpack-dev-middleware dependency (noticed due to changes in our npm-shrinkwrap.json) from version 1.6.1 to 1.8.1. Requesting any webpack bundled file results in a 404 (e.g. Cannot GET /compiled/application.js). Normally, this is returned when the file actually does not exist.

Webpack dev sever startup logs (scrubbed)

> webpack-dev-server --config config/webpack.config.js

 http://localhost:3808/webpack-dev-server/
webpack result is served from //localhost:3808/compiled/

Version: webpack 1.13.2

(Thousands of files)

webpack: bundle is now VALID.

Webpack config (simplified)

const path = require('path');
const webpack = require('webpack');
const StatsPlugin = require('stats-webpack-plugin');


const production = process.env.NODE_ENV === 'production' && process.env.CI === undefined;

const config = {
  entry: {
    application: './app/javascripts/application.js',
    specs: './app/javascripts/specs.js',
    legacy_application: './app/assets/javascripts/legacy_application.js',
    feature_group1: './app/assets/javascripts/feature_group1.js',
    feature_group2: './app/assets/javascripts/feature_group2.js',
    feature_group3: './app/assets/javascripts/feature_group3.js',
    legacy_external: './app/assets/javascripts/external.js',
    styleguide: './app/assets/javascripts/styleguide.js',
    signup: './app/javascripts/signup.js',
  },

  output: {
    path: path.join(__dirname, '..', 'public', 'compiled'),
    publicPath: '/compiled/',
    filename: production ? '[name]-[chunkhash].js' : '[name].js',
  },

  resolve: {
    root: path.join(__dirname, '..', 'app', 'javascripts'),
    extensions: ['', '.js', '.jsx', '.coffee'],
  },

  plugins: [
    new StatsPlugin('manifest.json', {
      chunkModules: false,
      source: false,
      chunks: false,
      modules: false,
      assets: true,
    }),
  ],
};

const plugins = [
  new webpack.NoErrorsPlugin(),
  new webpack.DefinePlugin({
    'process.env': { NODE_ENV: JSON.stringify('production') },
  }),
  new webpack.optimize.DedupePlugin(),
  new webpack.optimize.OccurenceOrderPlugin(),
];

if (production) {
  config.plugins.push(
    ...plugins,
    new webpack.optimize.UglifyJsPlugin({
      sourceMap: false,
      compressor: { warnings: false },
      output: { comments: false },
    })
  );
} else {
  config.devServer = {
    port: devServerPort,
    headers: { 'Access-Control-Allow-Origin': '*' },
  };

  config.output.publicPath = `//localhost:${devServerPort}/compiled/`;
  config.devtool = 'source-map';
}

module.exports = config;

Let me know if you need additional information.

Also, I'm not really sure what caused the bump in webpack-dev-middleware but I assume it should work since it is a minor version bump (but our monolithic app might need tweaking).

[juanca]

package.json (scrubbed)

{
  "dependencies": {
    "babel-core": "^6.14.0",
    "babel-loader": "^6.2.5",
    "babel-preset-es2015": "^6.14.0",
    "babel-preset-react": "^6.11.1",
    "backbone": "1.1.2",
    "backbone.marionette": "^1.8.8",
    "coffee-loader": "^0.7.2",
    "coffee-script": "^1.10.0",
    "eco-loader": "^0.1.0",
    "expose-loader": "^0.7.1",
    "filesize": "^3.3.0",
    "inflection": "^1.8.0",
    "jquery": "2.2.4",
    "moment": "^2.13.0",
    "react": "^15.3.0",
    "react-dom": "^15.3.0",
    "sprockets-preloader": "^0.9.10-b",
    "stats-webpack-plugin": "^0.2.1",
    "underscore": "1.4.4",
    "webpack": "^1.9.11"
  },
  "devDependencies": {
    "enzyme": "^2.4.1",
    "eslint": "^3.3.1",
    "eslint-config-airbnb": "^10.0.1",
    "eslint-loader": "^1.5.0",
    "eslint-plugin-import": "^1.13.0",
    "eslint-plugin-jsx-a11y": "^2.1.0",
    "eslint-plugin-react": "^6.1.2",
    "react-addons-test-utils": "^15.3.0",
    "webpack-dev-server": "^1.9.0"
  },
  "scripts": {
    "start": "./node_modules/.bin/webpack-dev-server --config config/webpack.config.js",
  },
  "engines": {
    "node": ">=6.0"
  }
}

[SpaceK33z]

Thanks for your extended information. You're right in that a minor version bump should not break anything in theory, but in practice this can be very difficult. Any change can have unintended side effects, especially because so many people use this package in different ways.

Two things:

• Can you try adding a protocol, https or http, to //localhost:${devServerPort}/compiled/? Something changed in the parsing of publicPath that may have introduced an error.
• If that doesn't work, can you try out version 1.7.0 and 1.8.0? That way we can narrow it down a bit.

[juanca]

Disclaimer: I'm still around. And I really appreciate your fast response(s)! I've been busy with a few other things for most of today.

However, I will do both and report on any changes.

One thing to add: I have another repo which just experienced the same thing. However, this other repo was not using a npm-shrinkwrap.json file. I'll also post its configuration details in the near future.

[SpaceK33z]

One thing to add: I have another repo which just experienced the same thing. However, this other repo was not using a npm-shrinkwrap.json file. I'll also post its configuration details in the near future.

It has nothing to do with npm-shrinkwrap, but it has the advantage now that you can jump to specific webpack-dev-middleware versions, which helps in pinpointing the problem.
Instead of posting the configuration details of another project, I'd rather have a test repo that reproduces the issue.

[razh]

Just encountered this issue while updating to 1.8.1.

url.parse() does not handle protocol-relative URLs, so the above recommendation of adding a protocol to publicPath worked for me.

https://github.com/webpack/webpack-dev-middleware/blob/v1.8.1/lib/GetFilenameFromUrl.js#L8

[SpaceK33z]

@razh, aha, thanks for the analysis. Would you mind doing a PR? Either way, please say so :).

[razh]

@SpaceK33z Sure, will do.

[juanca]

Just for historical purposes:

404 reproducible on:

• 1.8.1: yes
• 1.7.0: no
• 1.6.1: no

[parshap]

The issue was introduced in v1.8.0 with commit c4f4595 from PR #80. The fix was made in #129 but a new released has not yet been published to npm.

[juanca]

Awesome. Thanks!

Also for historical purposes: here is a simple repo which reproduces the bug.

Repo @ https://github.com/juanca/webpack-dev-middleware-404

• Works with [email protected]
• Breaks with [email protected]
• Works with [email protected] with a protocol specified

[SpaceK33z]

I'll release a new version tomorrow, I'm busy atm.

[SpaceK33z]

Published 1.8.2.