-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
baseUrl should handle full urls #2877
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
Comments
Thanks for bringing this up. It should be a bug report though, I f´think - at least the console output seems not right. |
@LinusBorg, I was going to make it a bug report but the helper format seemed too restricting with the reproduce steps requirement. I'm not sure if the console output is simply a cosmetic issue, or if there are other issues which occur when a full URL is provided. I haven't poked it enough to know. |
You can just create an example project and push it to github. Reproduction done. But I think we can get along without it in this case. ;) I've taken a look. So far, it really seems so be a cosmetic issue only. It's because so for the console output when running
... which is how the strange double-url in the console comes about. For the webpack config's |
Fixed in #2900 |
What problem does this feature solve?
Per the docs, "The base URL your application bundle will be deployed at. This is the equivalent of webpack's output.publicPath". In the webpack docs it's clear full urls are valid, one of the examples is 'https://cdn.example.com/assets/'.
From the docs for
devServer.publicPath
: "It is also possible to use a full URL. This is necessary for Hot Module Replacement." The point about HMR is clear when you look at issue 2525, where the HMR is using the wrong URL for updates.Setting
baseUrl
to a full URL results in a message fromvue-cli-service serve
such as:It does fix the HMR issue, since it plumbs down correctly, but
vue-cli
isn't treating it as the full URL that it is.If
baseUrl
is the equivalent of webpack'soutput.publicPath
as the docs say, then it must correctly handle full URLs. Otherwise they are not equivalent.What does the proposed API look like?
N/A
The text was updated successfully, but these errors were encountered: