Webpack-dev-server: historyApiFallback breaks with 2.1.0-beta.7 and 2.1.0-beta.6

[iam4x]

Before with this configuration the index file was served with 200.html since I've updated not anymore. Went through the PRs and documentation again I can't see what's wrong.

I'll just stick to beta.5 for now 👍

historyApiFallback: {
  index: '200.html'
}

[SpaceK33z]

This probably has to do with #617. Where does the 200.html file come from? Is it served through the contentBase option or from a webpack loader / plugin?

[SpaceK33z]

Never mind, found the issue and added a failing test.

@aves84, would you have time to look into this? #617 broke this (I don't blame you, at the time of this PR there weren't any tests). There are some unit tests for this now, so it would be easier.

[iam4x]

Thank's you for the fast answer and great investigation spreading some love 💖

fyi: 200.html it's like an index.html on the root of my project, but I use 200.html to make it work with surge.sh (static webapp hosting) https://surge.sh/help/adding-a-200-page-for-client-side-routing

[aves84]

I think 200.html is not valid request url, it shoud be like /200.html. In this case all works fine.
https://github.com/bripkens/connect-history-api-fallback/issues/9

[mac2000]

Got into similar issue, in our case we have few entry points (e.g. multiple apps in same repository)

Our webpack.config.babel.js is something like this one:

import path from 'path'
import webpack from 'webpack'

export default (app) => {
    console.log(`>>>>>>>> ${app} <<<<<<<<<<<`)
    return {
        entry: {
            app1: './entry/app1',
            app2: './entry/app2'
        },
        output: {
            path: path.join(__dirname, 'dist'),
            filename: '[name].js',
            publicPath: '/dist/'
        },
        devServer: {
            hot: true,
            //historyApiFallback: true
            historyApiFallback: {
                rewrites: [
                    { from: /.*/, to: `/entry/${app}.html` }
                ]
            }
        }
    }
}

package scripts is:

{
    "start:app1": "webpack-dev-server --env app1",
    "start:app2": "webpack-dev-server --env app2"
}

Starting from beta.6 rewrites stop working, the simplest way to reproduce it is even not to use entry points and/or outputs, just create few html files in entry folder and try to run webpack dev server to see what happend - directory index handler will be called

[SpaceK33z]

@aves84, you're right in that there should be a prepended slash, but even with it it doesn't work. Also see the tests in test/HistoryApiFallback.test.js.

[aves84]

@SpaceK33z As far I see all test in HistoryApiFallback.test.js successful, except "historyApiFallback should take preference above magicHtml" where for path / expected rewrites to /bar.html. But this case is wrong I think. Logically, path / exists - it is the root dir, so contentBase tries to serve index.html from there, and when not found, servs directory listing - https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L256.

For any unexisting path like /qwe there is correct rewrite to /bar.html. Such behavior looks pretty fine for me - for static files.

I dotn't fully understood webpack-dev-middleware and serveMagicHtml, so not sure what hapens for assets that serves from memory, but I think now everything should be correct.

[SpaceK33z]

@aves84, this would break a lot of existing use-cases, and I think that's not worth it.

The directory listing should serve as the _very_ last "fallback" that is used, because it doesn't provide that much info. Anything else then the directory index is more helpful for the end user.

Note that I just now realise I made a small mistake in naming the test: "magicHtml" should be "directory index".

[aves84]

Then it should be individual middleware adding the last instead adding within contentBase.

[mac2000]

@SpaceK33z, @aves84 just to help, after looking around for breaking commit I were able to make things work again (with rewrites or index prop) by putting historyApiFallback middleware before contentBase introduced here hope you guys will agree on something that will allow hold multiple apps inside repo

[SpaceK33z]

@mac2000, do you want to do a PR? Would be appreciated. There is a failing test in master now, so if all tests succeed again you know you've fixed it :).