vue单页面模板说明文档（3）

Environment Variables

Sometimes it is practical to have different config values according to the environment that the application is running in.

As an example:

// config/prod.env.js
module.exports = {
  NODE_ENV: '"production"',
  DEBUG_MODE: false,
  API_KEY: '"..."' // this is shared between all environments
}

// config/dev.env.js
module.exports = merge(prodEnv, {
  NODE_ENV: '"development"',
  DEBUG_MODE: true // this overrides the DEBUG_MODE value of prod.env
})

// config/test.env.js
module.exports = merge(devEnv, {
  NODE_ENV: '"testing"'
})

Note: string variables need to be wrapped into single and double quotes '"..."'

So, the environment variables are:

• Production
  • NODE_ENV = 'production',
  • DEBUG_MODE = false,
  • API_KEY = '...'
• Development
  • NODE_ENV = 'development',
  • DEBUG_MODE = true,
  • API_KEY = '...'
• Testing
  • NODE_ENV = 'testing',
  • DEBUG_MODE = true,
  • API_KEY = '...'

As we can see, test.env inherits the dev.env and the dev.env inherits the prod.env.

Usage

It is simple to use the environment variables in your code. For example:

Vue.config.productionTip = process.env.NODE_ENV === 'production'

Integrating with Backend Framework

If you are building a purely-static app (one that is deployed separately from the backend API), then you probably don't even need to edit config/index.js. However, if you want to integrate this template with an existing backend framework, e.g. Rails/Django/Laravel, which comes with their own project structures, you can edit config/index.js to directly generate front-end assets into your backend project.

Let's take a look at the default config/index.js:

// config/index.js
var path = require('path')

module.exports = {
  build: {
    index: path.resolve(__dirname, 'dist/index.html'),
    assetsRoot: path.resolve(__dirname, 'dist'),
    assetsSubDirectory: 'static',
    assetsPublicPath: '/',
    productionSourceMap: true
  },
  dev: {
    port: ,
    proxyTable: {}
  }
}

Inside the build section, we have the following options:

build.index

Must be an absolute path on your local file system.

This is where the index.html (with injected asset URLs) will be generated.

If you are using this template with a backend-framework, you can edit index.html accordingly and point this path to a view file rendered by your backend app, e.g. app/views/layouts/application.html.erb for a Rails app, or resources/views/index.blade.php for a Laravel app.

build.assetsRoot

Must be an absolute path on your local file system.

This should point to the root directory that contains all the static assets for your app. For example, public/ for both Rails/Laravel.

build.assetsSubDirectory

Nest webpack-generated assets under this directory in build.assetsRoot, so that they are not mixed with other files you may have in build.assetsRoot. For example, if build.assetsRoot is /path/to/dist, and build.assetsSubDirectory is static, then all Webpack assets will be generated in path/to/dist/static.

This directory will be cleaned before each build, so it should only contain assets generated by the build.

Files inside static/ will be copied into this directory as-is during build. This means if you change this prefix, all your absolute URLs referencing files in static/ will also need to be changed. See Handling Static Assets for more details.

build.assetsPublicPath

This should be the URL path where your build.assetsRoot will be served from over HTTP. In most cases, this will be root (/). Only change this if your backend framework serves static assets with a path prefix. Internally, this is passed to Webpack as output.publicPath.

build.productionSourceMap

Whether to generate source maps for production build.

dev.port

Specify the port for the dev server to listen to.

dev.proxyTable

Define proxy rules for the dev server. See API Proxying During Development for more details.

API Proxying During Development

When integrating this boilerplate with an existing backend, a common need is to access the backend API when using the dev server. To achieve that, we can run the dev server and the API backend side-by-side (or remotely), and let the dev server proxy all API requests to the actual backend.

To configure the proxy rules, edit dev.proxyTable option in config/index.js. The dev server is using http-proxy-middleware for proxying, so you should refer to its docs for detailed usage. But here's a simple example:

// config/index.js
module.exports = {
  // ...
  dev: {
    proxyTable: {
      // proxy all requests starting with /api to jsonplaceholder
      '/api': {
        target: 'http://jsonplaceholder.typicode.com',
        changeOrigin: true,
        pathRewrite: {
          '^/api': ''
        }
      }
    }
  }
}

The above example will proxy the request /api/posts/1 to http://jsonplaceholder.typicode.com/posts/1.

URL Matching

In addition to static urls you can also use glob patterns to match URLs, e.g. /api/**. See Context Matching for more details. In addition, you can provide a filter option that can be a custom function to determine whether a request should be proxied:

proxyTable: {
  '**': {
    target: 'http://jsonplaceholder.typicode.com',
    filter: function (pathname, req) {
      return pathname.match('^/api') && req.method === 'GET'
    }
  }
}