vue单页面模板说明文档（3）-CFANZ编程社区

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: 8080,
    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'
    }
  }
}