When using Vue for a separate project, the front end is usually deployed separately and the user accesses the front end project address, so it is important for the front end developer to familiarize himself with the process of project deployment and the solutions to various problems. Vue project package deployment itself is not complex, but some front-end students may not have much contact with the server, the deployment process will still encounter such and such problems. This article introduces the use of nginx server proxy front-end project method and project deployment related issues, content overview:

Preparations – Server and Nginx usage

1. Prepare a server

Mine is Ubuntu, and Linux works pretty much the same. How can we break it without a server?

If you just want to experiment, you can try free trial packages of cloud servers from various manufacturers, such as Huawei Cloud free trial, which is where this article is done. But if you want to practice from time to time, I think you can buy a cloud server, such as huawei cloud or Ali cloud are quite reliable. My personal website is deployed on Aliyun. You can click on my promotion link to purchase it. Recently, there was an event where the first purchase was less than 100 yuan per year.

2. Install and start nginx

This part will not be described too much (after all, there are a lot of relevant tutorials online). Under normal circumstances, only the following two instructions are required:

Sudo apt-get install nginx sudo apt-get install nginx sudo apt-get install nginxCopy the code

Once started, under normal circumstances, you should see the default page of the Nginx server by going directly to http://server IP or http://domain (the server you tested in this article was not configured with a domain name, so IP is used, for the purposes of this article, there is not much difference between domain and IP) — if not, It is possible that the default HTTP service port (port 80) of your cloud server is not open to the public. You can configure it in the server security group.

3. Learn about Nginx: Modify the Nginx configuration to let the Nginx server proxy the files we create

/etc/nginx/sites-available/default (nginx can have multiple configuration files, such as /etc/nginx/sites-available/default) Normally we configure nginx to also modify this file) :

By default, the root directory of the nginx proxy is /var/www/html. If you enter http://server IP, the files in this folder will be accessed. The default files, such as index.html or index.htm, will be found based on the configuration value of index.

We can change the root value to change the nginx service proxy folder:

  1. Create folder/WWW, create index.html, write “Hello world” string

    mkdir /www
    echo 'Hello world' > /www/index.html​
    Copy the code
  2. Change the root value to/WWW

Sudo nginx -t checks whether the nginx configuration is correct

  1. Sudo nginx -s reload
  2. Revisiting the page, we find that the page content has changed to the index.html we created:

Vue project package synchronization file to remote server

Pack 1.

By default, for projects created using vue-CLI, the script in package.json should already be configured with build directives. Simply execute YARN Build or NPM run build.

2. Synchronize data to the remote server

We deploy the Vue project using Nginx, essentially synchronizing the packaged contents of the Vue project to the folder pointed to by nginx. The previous steps have shown how to configure nginx to point to the folder we created. The remaining problem is how to synchronize the packaged files to the specified folder on the server, such as/WWW. To synchronize files, you can use the SCP command in git-bash or powershell, or the rsync command in Linux:

Scp-r dist/* [email protected]:/ WWW or rsync-avr --delete-after dist/* [email protected]:/ WWWCopy the code

Note here and the following steps that root uses user remote synchronization and should replace root and IP (IP with your own server IP) as appropriate for your situation.

For convenience, add a push command to your package.json script, using yarn as an example (if you are using NPM, change yarn to NPM run in push) :

  "scripts": {
    "build": "vue-cli-service build",
    "push": "yarn build && scp -r dist/* [email protected]:/www"
  },
Copy the code

This allows you to do yarn push or NPM run push directly. There is a small problem, however, is that the command execution requires the user root password of the remote server.

To avoid entering the root password for each execution, we can synchronize the local SSH to the authorized_keys file on the remote server.

3. Synchronize the SSH key

  1. Generate an SSH key: Use Git bash or powershell to run ssh-keygen to generate an SSH key. If the key already exists, it will ask whether to overwrite it:

  2. To synchronize the SSH key to the remote server, run the ssh-copy-id command

    SSH - copy - id - I ~ /. SSH/id_rsa pub [email protected]Copy the code



After you enter the password, you do not need to enter the password again. ~/.ssh/authorized_keys ~/.ssh/authorized_keys



You can also manually copy the contents of the local ~/.ssh/id_rsa.pub fileadditional~/.ssh/authorized_keys (this file can store multiple SSH keys, as you can see from the name)

Note: the root user is used in the whole process, so there is no file operation permission problem. If the user who created the folder is not a remote login user, files may fail to be synchronized. In this case, you need to run the chmod command on the remote server to change the read and write permissions of the folder.

Create a test project (click on this link to view it on Gihub) and try it out. Pack and upload files.

Sure enough, we see the familiar interface:

Now that I’ve covered the normal publishing Vue project, I’ll cover publishing under non-domain root paths and publishing in history routing mode.

Non-domain root path advertising

Sometimes the same server under the same port may be divided into several different projects according to the directory, for example, we want to deploy the project under a.com/test, so as to access h…

1. The nginx configuration

All you need to do is add a location rule that assigns access paths and specifies access folders. /test = ‘/ WWW’; /test = ‘/ WWW’; / WWW = ‘WWW’;

If the folder name and access path are both test, then you can use root to configure:

The /test configuration is placed before /, which means that /test will be matched when the route enters. If the project under the root path/has a child path /test, http://xxxx/test will only access the project in/WWW, not the child path.

2. Configure the project

To solve the problem of incorrect resource paths after packaging, you need to configure publicPath in vue.config.js. Set publicPath to./ and /test respectively.

Update the nginx configuration to be accessible once published. There are differences between the two configurations, and we’ll look at the differences. If the project is not configured, the issue of blank pages may occur when JS, CSS and other resources cannot be found:

This is because the resource reference path is incorrect. The page review element can see that the js referenced by the page is referenced from the root path:

Js/CSS /img/static files are at the same level as index.html:

For both configurations, see how they work:

  1. If publicPath is set to./, the reference path of packaged resources is a relative path.

  2. If publicPath is set to /test, the relative path of packaged resources is the absolute path starting from the root directory of the domain name.

In both configurations, resources such as JS and CSS can be found correctly. The problem is that static resources in static are still missing.

3. Static resources referenced by absolute paths cannot be found

Since static resources under public are not processed by WebPack during the packaging process, we need to refer to them via an absolute path. This can be a headache when the project is deployed to a non-root path, and you need to prefix each referenced URL with process.env.base_URL (which corresponds to the publicPath configured above) to make the resource accessible. We can bind this variable value to vue. prototype in main.js so that every Vue component can use it:

Vue.prototype.$pb = process.env.BASE_URL
Copy the code

Use in templates:

<img :src="`${$pb}static/logo.png`">
Copy the code

However, a more troubling and poorly resolved problem is using static resources under the public folder in the component’s style section:

  • If you need to use images as background images, use them inline as you would in a template.
  • If you need to introduce style files, use interpolation in index.html.

With respect to static resources, vue-CLI’s recommendation is to try to import resources as part of your module dependency graph (i.e. into assets, using a relative path reference). This avoids this problem and brings other benefits:

Iv. Deployment in History mode

By default, Vue projects use hash routing, which is the form of a hash in the URL. The hash and subsequent content is the hash part of the route address. Normally, when the browser address bar is changed, the browser will reload the page, but not if the hash part is changed. This is the principle of front-end routing, which allows partial page updates without refreshing the entire page based on different routes. H5 has added a pushState interface for History, which also allows front-end operations to change routing addresses without triggering page refreshes. Therefore, using history mode can remove # signs from routes.

1. Project configuration

Configure the mode and base options in vue-router routing options, and set mode to ‘history’. If the domain name is deployed to a non-root directory, you also need to set the base option to the publicPath value. Note that in this case, publicPath must be configured in the absolute path /test format instead of the relative path./.

2. The nginx configuration

For the history mode, suppose the project is deployed to the /test directory under the domain name. When accessing http://xxx/test/about, the server will look for the about subdirectory or file under the directory pointed to by /test. Obviously, since it is a single-page application, the directory or file A does not exist. This results in a 404 error:

We need to configure Nginx so that in this case, the server can return the index.html of the single-page application, and then the front-end will do the rest of the routing parsing.

/test/index.html = /test/index.html = /test/index.html = /test/index.html = /test/index.html = /test/index.html = /test/index.html Open the about address again and the page will not be 404:

3. Deploy the domain name in history mode to a non-domain name root path

If the domain name is not the root directory, you must configure publicPath first. Note that in this case you cannot use a relative path or an empty string to configure publicPath. Why is that? The reason for this is that it can lead to disordered performance of router-link, etc., and use test projects to package the distribution with two configurations separately and review the elements to see the difference. There are two router-links on the page, Home and About:

The result of the two configurations is as follows.

  1. Set publicPath to./ or empty string:

  2. Set publicPath to /test.

The router-link address configured as a relative path is changed to an address under the relative root domain name. This is obviously incorrect. Therefore, in non-domain root path deployment, configure publicPath as a full prefix path.