New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is the middlewares ordering correct? #869
Comments
I think the argument is valid, and we should probably provide more options for middleware overrides. I could see We'd happily review a Pull Request to extend the functionality there. |
@shellscape if we agree on 'pre' and 'post', I can submit a PR, however, I DO think the current order is just not correct. I'd expect the I've stumbled upon an issue with how it is setup currently, so I'd rather like to submit a PR for the correct ordering, instead of adding additional hooks. My current workaround is, using the undocumented |
@mrtnbroder this is where Git blame comes in handy; Add setup option to prepend custom middlewares #279. In the context/angle you're viewing this from, the middleware ordering doesn't look correct because of the behavior you're seeing and the goal you're trying to achieve. However, there was a good reason that So I'd argue that we don't want to move the position of |
I don't see a usecase for
|
I'm not sure I agree with your proposed approach. I see const server = new Server(compiler, {
middleware: {
pre: () => { },
post: () => { }
}
}); and while I'm thinking on it, a better pattern here that everyone is probably already familiar with if they've done any kind of test writing: const server = new Server(compiler, {
middleware: {
before: () => { }, // applied before the built-in middleware
after: () => { } // applied after the built-in middleware
}
});
|
But I'd try to stick to this pattern. Agreed? |
Perhaps in the context of a webpack |
As per this line
https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L320
the middlewares ordering is
["setup", "headers", "middleware"]
. Due to this if i have a middleware for * in setup, it will consume all wepack output routes as well. For e.xsetup: function(app) { app.use('*', function(req, res) { res.render('index'); }) }
this configuration will server index html even for all webpack bundle paths.But if the middleware ordering is
[ "headers", "middleware", "setup"]
, this problem won't occur.Wepack: 2.2.1
Webpack-dev-server: 2.3.0
The text was updated successfully, but these errors were encountered: