Created by: gaearon
Migration Instructions
Paths like /src/somefile.png used to be served in development, but only by accident. They never worked in production builds. Since 0.4.0, we don’t serve static files by default in development anymore either. This removes a dangerous inconsistency that we never intentionally supported.
If you need a static file to be part for the build, import it from JavaScript and you will get its filename. This ensures it gets included into the production build as well, and its filename contains the content hash.
If you used static files with <link href>, read this new guide on how to make sure these files get included into the builds. For example, you can replace <link href="/src/favicons/favicon-32.png"> with <link href="./src/favicons/favicon-32.png">, and then Webpack will recognize it and include it into the build.
If you referenced some other files from index.html, please file an issue to discuss your use case. In the meantime, you can serve them from a separate static server until your use case is supported.
Fixes #503 (closed) (it was never intentionally supported). Supersedes #226 (I think there is not enough proof that this feature is necessary after #428). Documents #428.
I understand this will be somewhat controversial because people might rely on this, but if they do, their production builds are already broken right now. This brings our features to consistency and documents the escape hatch that I believe removes the need for #226.
Justification in the comment:
+ // By default WebpackDevServer also serves files from the current directory.
+ // This might be useful in legacy apps. However we already encourage people
+ // to use Webpack for importing assets in the code, so we don't need to
+ // additionally serve files by their filenames. Otherwise, even if it
+ // works in development, those files will be missing in production, unless
+ // we explicitly copy them. But even if we copy the all the files into
+ // the build output (which doesn't seem to be wise because it may contain
+ // private information such as files with API keys, for example), we would
+ // still have a problem. Since the filenames would be the same every time,
+ // browsers would cache their content, and updating file content would not
+ // work correctly. This is easily solved by importing assets through Webpack
+ // because if it can then append content hashes to filenames in production,
+ // just like it does for JS and CSS. And because we configured "html" loader
+ // to be used for HTML files, even <link href="./src/something.png"> would
+ // get resolved correctly by Webpack and handled both in development and
+ // in production without actually serving it by that path.