Record of the actual process of packaging and deployment of Vue project

Preface

When using Vue to separate the front-end and back-end projects, the front-end is usually deployed separately, and users also access the front-end project address. Therefore, it is very necessary for front-end developers to be familiar with the project deployment process and solutions to various problems. The packaging and deployment of the Vue project itself is not complicated, but some front-end students may not have much contact with servers and may still encounter various problems during the deployment process. This article introduces the method of using nginx server to proxy front-end projects and related issues of project deployment. Content overview:

1. Preparation - Server and nginx usage

1. Prepare a server

I use Ubuntu system, and the operations of Linux system are similar. What if there is no server?

If you just want to experience it, you can try the free trial packages of cloud servers from major manufacturers, such as the Huawei Cloud free trial. The relevant operations in this article are completed on Huawei Cloud. However, if you want to practice frequently, I think you can buy a cloud server, such as the Huawei Cloud or Alibaba Cloud mentioned above, which are quite reliable. My personal website is deployed on Alibaba Cloud. You can click on my promotion link to make a purchase. There is an event recently where the first purchase is less than 100 yuan/year.

2. Install and start nginx

Travel light, I won't go into too much detail on this part (after all, there are a lot of relevant tutorials online). Under normal circumstances, only the following two commands are needed:

# Install. After the installation is complete, use nginx -v to check. If the output of nginx version information indicates that the installation is successful sudo apt-get install nginx
# Start sudo service nginx start

After startup, under normal circumstances, you should be able to see the default page of the nginx server by directly accessing http://server ip or http://domain name (the server used in this article is not configured with a domain name, so the ip is used. As far as this article is concerned, there is not much difference between the domain name and the ip). If you cannot access it, it may be that the default http service port (port 80) of your cloud server is not open to the outside world. Just configure it in the server security group.

3. Understand nginx: Modify the nginx configuration to let the nginx server proxy the files we created

Check the configuration of nginx. The configuration files under Linux system are usually stored in the /etc directory. The configuration files of nginx are in the /etc/nginx folder. Open the file /etc/nginx/sites-available/default (nginx can have multiple configuration files. Usually we configure nginx by modifying this file):

You can see that by default, the root directory of the nginx proxy is /var/www/html. Entering http://server ip will access the files in this folder, and the default access files will be found according to the configuration value of index, such as index.html, index.htm, etc.

We can change the root value to modify the folder where the nginx service proxy is located:

Create a folder /www and create index.html, and write the string "Hello world"

mkdir /www
echo 'Hello world' > /www/index.html

Change the root value to /www

sudo nginx -t Check whether the nginx configuration is correct

Load nginx configuration: sudo nginx -s reload

Visit the page again and find that the page content has become the index.html we created:

2. Vue project packaging and synchronization files to remote server

1. Packaging

By default, for projects created with vue-cli, the script in package.json should have been configured with build instructions, and you can directly execute yarn build or npm run build.

2. Synchronize to remote server

We use nginx to deploy the Vue project, which essentially synchronizes the packaged contents of the Vue project to the folder pointed to by nginx. The previous steps have already introduced how to configure nginx to point to the folder we created. The remaining question is how to synchronize the packaged files to the specified folder on the server, such as synchronizing to the /www created in the previous step. To synchronize files, you can use the scp command in git-bash or powershell. If you are developing in a Linux environment, you can also use the rsync command:

scp -r dist/* [email protected]:/www
or rsync -avr --delete-after dist/* [email protected]:/www

Note that here and in the subsequent steps, root is used for remote synchronization. You should replace root and ip according to your specific situation (ip is replaced by your own server IP).

For convenience, you can add a push command in the package.json script, taking yarn as an example (if you use npm, just change yarn in the push command to npm run):

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

In this way, you can directly execute yarn push or npm run push to publish directly. However, there is still a small problem, that is, when the command is executed, you are required to enter the root password of the remote server (root is used here to connect to the remote, you can use other users, after all, the root user has too high permissions).

In order to avoid entering the root password every time we execute the command, we can synchronize the local ssh to the authorized_keys file of the remote server.

3. Synchronize SSH key

Generate ssh key: Use git bash or powershell to execute ssh-keygen to generate ssh key. You will be asked for the storage address of the generated key. Just press Enter. If it already exists, you will be asked whether to overwrite it:

Synchronize ssh key to the remote server, use the ssh-copy-id command to synchronize

ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected] 

After entering the password, you do not need to enter the password again when syncing. In fact, ssh_key is synchronized to the server (here is the root user's home directory) ~/.ssh/authorized_keys file:

Of course, you can also manually copy the local ~/.ssh/id_rsa.pub (note that it is a public key ending with pub) file content and append it to the server ~/.ssh/authorized_keys (from the name, you can see that this file can store multiple ssh keys)

Note: The root user is used throughout the process, so there is no file operation permission issue. If the user who created your folder is not a remote login user, there may be a problem with file synchronization failure. In this case, the remote server needs to modify the read and write permissions of the folder (command chmod).

I created a test project (click this link to view it on GitHub) [1] and gave it a try. Packaging and file uploading can be done with just one command:

After visiting it, we can see the familiar interface:

So far, the introduction to publishing Vue projects under normal circumstances has been completed. Next, we will introduce the publishing method under non-domain root path and history routing mode.

3. Non-domain root path release

Sometimes, the same server and the same port may have multiple different projects divided according to the directory. For example, we want to deploy the project to http://a.com/test, so that visiting http://a.com/test will access the project's homepage, while the address without the prefix test will access other projects. At this time, you need to modify the nginx configuration and Vue packaging configuration.

1. nginx configuration

You only need to add a location rule, assign the access path and specify the access folder. We can point /test to the /www folder we created earlier. Because the folder name and access path are inconsistent, we need to use the alias configuration:

Here, we need to put the /test configuration before /, which means that when the route enters, /test will be matched first. If the project under the root path / has a sub-route /test, then http://xxxx/test will only access the project in /www, but not the sub-route.

2. Project Configuration

In order to solve the problem of incorrect resource path after packaging, you need to configure publicPath in vue.config.js. There are two configuration methods, configuring publicPath to ./ and /test respectively:

Update the nginx configuration and you can access it normally after publishing. There are differences between the two configuration methods here. Let's take a look at their differences. If you do not configure the project and directly publish the access, the JS, CSS and other resources may not be found, resulting in a blank page:

The reason for this problem is that the resource reference path is incorrect. The page review element shows that the js referenced by the page is referenced from the root path:

Looking at the packaged file structure, you can see that resource files such as js/css/img/static are at the same level as index.html:

publicPath is configured as ./, and the resource reference path after packaging is a relative path:

publicPath is configured as /test, and the relative path of the packaged resource is the absolute path starting from the root directory of the domain name:

Both configurations can correctly find JS, CSS and other resources. However, there is still a problem, that is, the static resources in static still cannot be found.

3. The problem of static resources referenced by absolute paths not being found

Because during the packaging process, public static resources will not be processed by webpack, we need to reference them through absolute paths. When the project is deployed to a non-domain root path, this is very troublesome. You need to add process.env.BASE_URL (the value corresponds to the publicPath configured above) in front of each referenced URL so that the resources can be accessed normally. 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

Use in template:

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

However, a more troublesome problem that has no good solution is to use static resources in the public folder in the component style:

• If you need to use an image as a background image, etc., try to use it inline, just like using it in a template.
• If you need to import a style file, use interpolation to import it in index.html.

Regarding the issue of static resources, vue-cli recommends that you try to import resources as part of your module dependency graph (that is, put them in assets and use relative path references). Avoiding this problem also brings other benefits:

IV. History Mode Deployment

By default, the Vue project uses the hash routing mode, which means that the URL contains a # sign. The # sign and the content after it are the hash part of the routing address. Normally, when the address in the browser address bar changes, the browser will reload the page, but if the hash part is modified, it will not. This is the principle of front-end routing, which allows partial updates of the page according to different routes without refreshing the entire page. H5 has added a pushState interface for history, which also allows front-end operations to change the routing address without triggering a page refresh. The history mode is implemented using this interface. Therefore, using history mode can remove the # sign in the route.

1. Project Configuration

Configure the mode option and base option in the vue-router routing options, and set the mode to 'history'; if deployed to a non-domain root directory, you also need to configure the base option to the publicPath value configured above (Note: In this case, publicPath must use the absolute path /test configuration format, not the relative path ./)

2. nginx configuration

For history mode, assuming that 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, because it is a single-page application, there will be no directory or file a, which will result 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 rest of the routing parsing can be done by the front end.

3. History mode is deployed to a non-domain root path

When deploying in a non-domain root directory, you must first configure publicPath. The point that needs attention has actually been mentioned before, that is, in this case, you cannot use the relative path ./ or the empty string to configure the publicPath. Why?

The reason is that it will cause the performance of router-link and other functions to be disrupted. Use the test project [2] to package and publish the two configurations respectively. The difference can be seen by reviewing the elements. There are two router-links on the page, Home and About:

The results of the two configurations after packaging are as follows.

publicPath is configured as ./ or an empty string:

publicPath is configured as /test:

After the router-link package is configured with publicPath as a relative path, the address becomes the address relative to the root domain name, which is obviously wrong. Therefore, for non-domain root path deployment, publicPath should be configured as a complete prefix path.

V. Conclusion

That’s all I have to say about the release of the Vue project. I have experienced this only after going through the pitfalls at almost every step. If you have any questions, you are welcome to discuss them with me.

References

[1] Vue project package release: https://github.com/Lushenggang/vue-publish-test

[2] Vue project packaging deployment test project address: https://github.com/Lushenggang/vue-publish-test

This is the end of this article about Vue project packaging and deployment. For more relevant Vue project packaging and deployment content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!