devServer proxy option as string not working as expected

[ksmithut]

Version

3.0.3

Reproduction link

https://github.com/ksmithut/vue-devserver-proxy-test

Node and OS info

Node v10.10.0 / yarn 1.9.4 / macOS 10.13.6

Steps to reproduce

Install Dependencies

yarn

Start server(s)

yarn start.dev # will start the vue dev server as well as another server which should be proxied to.

Make Requests

1. Go to http://localhost:8080, will show the default vue page. Expected
2. Go to http://localhost:3001/meow, will show mix . Expected
3. Go to http://localhost:8080/meow, will show a blank page with the "home" and "about" links at the top. Not Expected

What is expected?

It was expected based on this documentation that setting a string for the "devServer.proxy" option would proxy all not-known requests to the configured proxy in vue.config.js, and a call to http://localhost:8080/meow would be the same result as http://localhost:3001/meow.

What is actually happening?

The request is not being proxied to the configured proxy server per the docs.

---

If the specific paths are configured in the proxy object, it seems to work fine.

Also, perhaps this is due to the "history" mode being used for the router, but it would be nice to have some sort of workaround as it doesn't mimic production behavior. I also understand I need to setup my server to send all non-matched paths to the built index.html, but I wasn't going to put in that effort unless I could get the proxy to work.

[LinusBorg]

Thanks. Seems to be a bug.

It works as expected with this config, which should be the "long-form" of the short string based form:

module.exports = {
  devServer: {
    proxy: {
      "/": {
        target: "http://localhost:3001"
      }
    }
  }
};

[ksmithut]

Confirmed that the root path works with that workaround, but if you go to http://localhost:8080/about, then it proxies the request to to the backend, at which point the backend would need to resolve to the index.html, but it would resolve to the built one, and not the one being served by webpack-dev-server. I'm not sure what the right answer for this is because if you are leveraging the browser history, the webpack dev server will need to know about the client routes. Seems like a lot of edge cases.

[haoqunjiang]

See here:

vue-cli/packages/@vue/cli-service/lib/util/prepareProxy.js

Lines 72 to 79 in 8a54ef6

	// Heuristics: if request `accept`s text/html, we pick /index.html.
	// Modern browsers include text/html into `accept` header when navigating.
	// However API calls like `fetch()` won’t generally accept text/html.
	// If this heuristic doesn’t work well for you, use a custom `proxy` object.
	return (
	req.headers.accept &&
	req.headers.accept.indexOf('text/html') === -1
	)

So it's not a bug but a documentation issue.

[haoqunjiang]

This only happens when you directly visit this url in browser. fetch('/meow') will work as expected.

[fancydev18]

How to handle the usecase pointed out by @ksmithut ?

This only happens when you directly visit this url in browser.

This happens every time on localhost when using history mode and making a change in Vue source code. Page will reload and browser will give 404.

I tried

    proxy: {
      "**": {
        target: "http://localhost:5000"
      }
    }

which should work according to this page linked from Vue docs
https://github.com/chimurai/http-proxy-middleware#proxycontext-config

but it gives

SyntaxError: Invalid regular expression: /**/: Nothing to repeat

[fancydev18]

Actually, '**' would be the wrong solution, since we don't want "/about" to be handled by the backend server. It should be handled by Vue dev server, since the cause is route history mode.
Note, production handles this differently, still from frontend server.

if you are leveraging the browser history, the webpack dev server will need to know about the client routes

Right, or maybe just handle everything which wasn't explicitly proxied.