vuejs / vue-cli

🛠️ webpack-based tooling for Vue.js Development
https://cli.vuejs.org/
MIT License
29.76k stars 6.33k forks source link

process.env.BASE_URL does not return a URL #5828

Open unikitty37 opened 4 years ago

unikitty37 commented 4 years ago

Version

4.5.4

Reproduction link

https://github.com/unikitty37/vue-cli-base-url-demo

Environment info


Environment Info:

  System:
    OS: macOS Mojave 10.14.6
    CPU: (24) x64 Intel(R) Xeon(R) CPU           X5690  @ 3.47GHz
  Binaries:
    Node: 14.4.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.7 - /usr/local/bin/npm
  Browsers:
    Chrome: Not Found
    Edge: Not Found
    Firefox: Not Found
    Safari: 13.1.2
  npmPackages:
    @clampy-js/vue-clampy: ^1.0.6 => 1.0.6 
    @testing-library/vue: ^5.0.4 => 5.0.4 
    @types/testing-library__vue:  2.0.3 
    @vue/babel-helper-vue-jsx-merge-props:  1.0.0 
    @vue/babel-plugin-transform-vue-jsx:  1.1.2 
    @vue/babel-preset-app:  4.4.6 
    @vue/babel-preset-jsx:  1.1.2 
    @vue/babel-sugar-functional-vue:  1.1.2 
    @vue/babel-sugar-inject-h:  1.1.2 
    @vue/babel-sugar-v-model:  1.1.2 
    @vue/babel-sugar-v-on:  1.1.2 
    @vue/cli-overlay:  4.4.6 
    @vue/cli-plugin-babel: ~4.4.0 => 4.4.6 
    @vue/cli-plugin-e2e-nightwatch: ~4.4.0 => 4.4.6 
    @vue/cli-plugin-eslint: ~4.4.0 => 4.4.6 
    @vue/cli-plugin-router: ~4.4.0 => 4.4.6 
    @vue/cli-plugin-unit-jest: ~4.4.0 => 4.4.6 
    @vue/cli-plugin-vuex: ~4.4.0 => 4.4.6 
    @vue/cli-service: ~4.4.0 => 4.4.6 
    @vue/cli-shared-utils:  4.4.6 
    @vue/component-compiler-utils:  3.2.0 
    @vue/preload-webpack-plugin:  1.1.2 
    @vue/test-utils: ^1.0.3 => 1.0.3 
    @vue/web-component-wrapper:  1.2.0 
    eslint-plugin-vue: ^6.2.2 => 6.2.2 
    jest-serializer-vue:  2.0.2 
    vue: ^2.6.11 => 2.6.11 
    vue-eslint-parser:  7.1.0 
    vue-hot-reload-api:  2.3.4 
    vue-jest:  3.0.6 
    vue-loader:  15.9.3 
    vue-router: ^3.2.0 => 3.3.4 (3.4.3)
    vue-style-loader:  4.1.2 
    vue-template-compiler: ^2.6.11 => 2.6.11 
    vue-template-es2015-compiler:  1.9.1 
    vuex: ^3.4.0 => 3.5.1 
  npmGlobalPackages:
    @vue/cli: 4.4.6

Steps to reproduce

What is expected?

The page should read Base URL is http://localhost:8080/.

What is actually happening?

The page reads Base URL is /.


This is not a URL, it's a path. This should really be returned under process.env.BASE_PATH — but I'd argue that process.env.BASE_URL should exist as well, and should return the full http://localhost:8080/ in this case.

I need to create a link that will allow the user to add this site's ICS feed to their Google Calendar easily, but this does not return the base URL:

googleICSFeed () {
  return `https://calendar.google.com/calendar/render?cid=${ process.env.BASE_URL }/calendar.ics`
},

https://cli.vuejs.org/guide/mode-and-env.html#using-env-variables-in-client-side-code does state that BASE_URL returns a path rather than a URL, but it would be much better to document how to actually get this URL, even if the variable is not renamed to reflect what it actually contains…

jeneser commented 4 years ago

BASE_URL - this corresponds to the publicPath option in vue.config.js and is the base path your app is deployed at. reference.

You can specify http://localhost:8080/ using publicPath option in vue.config.js.

// vue.config.js

module.exports = {
  publicPath: process.env.NODE_ENV === 'production'
    ? 'http://foobar.com/'
    : 'http://localhost:8080/'
}

Note: our app won't work if BASE_URL is deployed at different origin. AFAIK, we always provide process.env.BASE_URL, but by default it's a path not url.

unikitty37 commented 4 years ago

Thanks — but that's how to set it, not to read it :)

jeneser commented 4 years ago

read it ? Just like:

googleICSFeed () {
  return `https://calendar.google.com/calendar/render?cid=${ process.env.BASE_URL }/calendar.ics`
},

Is there any doubt?

tobius commented 1 year ago

I just encountered this same issue and I'm very much with @unikitty37. I introduced some build bugs into a new Docker configuration PR this week that didn't make sense. It was all because of this very poorly named variable.

I wonder how many other Developers this has confused over the years? I'd be willing to bet it's a pretty high number.

URL was standardized by Tim Berners-Lee in 1994 via RFC 1738. It stands for Uniform Resource Locator. It is used to locate a network resource in a uniform way. The different parts of a URL are:

{protocol}://[{user}:{password}@]{host}[:port][{/path}]

A very practical usage of a URL is typing one into a Web Browser to go to a web page.

If you type "https://github.com/vuejs/vue-cli" into your browser you will visit that page, because this is a URL. If you type "/vuejs/vue-cli" into your browser you will NOT visit that page, because this is the path value of a URL.

Note: Because someone might ask. The only reason this might "seem" to work in the context of developing a single web application is because, in your code, you can link an "href" to a path and your Web Browser's rendering engine will interpret it as an absolute path (if it begins with /) or a relative path (if it does not begin with /) and appropriately inject that path value into the current browser windows URL to form a new URL that can be followed. It's still a path, and not a URL.

The environment variable BASE_URL should be renamed to BASE_PATH. A "new" environment variable named BASE_URL should be re-added. Backward compatible code to figure out which is which (to take the burden off of the current users) should be added as well, with a deprecation warning because this shouldn't be left this way long-term. After a couple of major releases the backward compatible code should be removed. My 2¢.