Content base should have precedence over proxy

[jacobp100]

• Operating System: Windows 10
• Node Version: 8.5
• NPM Version: 5
• webpack Version: 3.1
• webpack-dev-server Version: 2.9.1

• This is a bug
• This is a feature request
• This is a modification request

Code

  // webpack.config.js
{
  contentBase: path.join(process.cwd(), "public"),
  proxy: {
    "/": {
      target: <ourQaServer>
    },
  }
}

Expected Behavior

Content base has priority

Actual Behavior

Proxy has priority

For Bugs; How can we reproduce the behavior?

• Have file with filename public/style.css
• Access /style.css
• It will try (and) fail to get this from the proxy

For Features; What is the motivation and/or use-case for the feature?

This is confusing behaviour.

This is a repost of #1131. I'm happy to submit a PR if you're happy to change this.

[shellscape]

@jacobp100 I know that unfamiliar systems can be a tad confusing at first. Some helpful tips:

• when an issue is closed, it can still be commented on, unless it's been locked. your prior issue that was closed as invalid wasn't locked. it's always best to stick to the original issue over reposting a duplicate (we typically close duplicates as well)
• you can always edit your original post, and that's a better practice than creating a duplicate issue
• it looks like you may have missed the bit in the Issue Template that reads: Please do remove this header to acknowledge this message.. we curate our templates to be the most useful to both users and our efforts maintaining the project, so please do read them thoroughly

I examined the history behind the proxy feature and how it works with contentBase by examining the git blame for proxy and searching through older issues (they're always there to search, issues are never deleted). The behavior is by design, and unfortunately since you're proxying the root, that will take precedence.

[jacobp100]

@shellscape I did some searching, but I couldn't find much. I can only find #127, where the order was questioned, although not answered. If its by design, did your examination dig up any history on why that decision was made? Otherwise, I'm not sure I see the use-case for a proxy taking precedence.

I think this is particularly confusing because http-server serves static files in precedence to proxying.

[shellscape]

This goes back 2+ years https://github.com/webpack/webpack-dev-server/blame/50a2e10153c5541fbc03434fcb496e09bc140440/lib/Server.js to when proxy was first implemented, and then to https://github.com/webpack/webpack-dev-server/blame/e6ccbaffc30bdcbc74285d30d1d93c0109019654/lib/Server.js#L336 when the defaultFeatures order was established about a year ago, which resolved #612 in PR #613. Those are the reasons for the established order 🦄

[jacobp100]

Just trying to understand this. Is the idea that with each proxy config, you can either (but not both):

• Define a URL to fetch resources from
• Redirect resources to a later proxy or contentBase

[shellscape]

I think this is particularly confusing because http-server serves static files in precedence to proxying.

If you would be so kind as to paste the links to the docs or a working example that could show this, I think it would be a reasonable change to make for version 3, which is currently in progress. That'd be a breaking change, so it'd have to go into a major version. Version 3 is currently being worked on in the beta branch.

[jacobp100]

Absolutely! In the docs it reads,

-P or --proxy Proxies all requests which can't be resolved locally to the given url. e.g.: -P http://someurl.com

To me it seems like the current proxy is conflating wanting to redirect files (I.e. a.js to b.js) and reverse proxies.

Would it make sense to pull out the bypass into its own top-level config? We would be free to make contentBase run after bypass but before proxy so we don’t break people’s current use cases.

Happy to submit code for this btw!

[shellscape]

Let's dive a little deeper into this before getting to code. You're linking to a third-party module (http-server) which isn't a core node module, so we can't use that README as an argument for the change because it's not a standard, but just the way that module happens to handle things. That is unless of course you can dig up documentation from https://nodejs.org/en/docs/ that suggests the way that webpack-dev-server has it setup is incorrect. That's the kind of docs we're going to need to justify a big change like this. (express.js can also be considered an authority here, since WDS uses express under the hood to create a server)

[jacobp100]

I see the confusion—sorry about that! I linked it because it’s a very popular package.

I don’t think node has a built-in proxy or static file server, and express is dependent on how you set up the middleware.

Would it be finding more projects like http-server and getting data on what they do?

Other than that, did my comment about the bypass and proxy splitting make sense?

[shellscape]

Yeah I think we need more documentation to form a non-official but aggregated standard to back up the change. I get what you're saying about bypass and proxy but without a strong case for making those changes it's a tough sell.

[jacobp100]

I've now gone through quite a lot of pages of http-server-like projects.

A lot of them didn't support proxying. Others did an express-style routes configuration, where you decide the priority of proxies over the static content. I have not included these projects as they don't make a decision on this.

Below is the projects that I found that included proxies and static content, and made a decision about ordering. I've included the downloads per month.

Static files win over proxy

• http-server (435,346/month)
• live-server (113,440/month)
• http2-server (11/month)

Proxy wins over static files

• local-web-server (16,450/month)
• freddie (185/month)

Unsure

• impress (2,254/month)

[shellscape]

After spending some time thinking about this, my conclusion is that there isn't a "right way" to go about this ordering of precedence. Either way you go, there are people who will expect it differently. @jacobp100 you're firmly in one camp, perhaps out of necessity, but it's reasonable to say that there will be many others in the other camp.

To that end, we need to devise a meaningful way to adjust the order by which things are positioned in the "features" stack; an array that is put together to assign middleware in a particular order. That'll have to be given some thought as well in order to do that "right."