The reason

Before, I worked in YW Company for an old project, vUE project, which lasted for 2 years. During development, it took five minutes to start up. Compilation is also slow. As a front-end with a desire for development experience, it’s unbearable. So at a stroke of luck, the project was upgraded. The original VUECLI2 became VUECLI4. Compilation started in 1 minute instead of 5 minutes, and regular code compilation was also improved.

teasing

Didn’t you quit before? I will bring up my ability to migrate projects. But basically these companies don’t pay attention, or don’t care. I think the project manager is more about stability. It just works. I don’t know if I did the right thing. But shouldn’t you, as a project manager, be responsible for ensuring that the project is sustainably maintained?

Another is that a lot of companies think you’re just a little thing, right? And put it on display. Well, why don’t you, please? Can’t you do it without hitting B?

Hearing that I just turned cli2 into Cli4 makes me feel like I have nothing to say. Do you know how many holes there are?

Migration behavior analysis

1. The newer the project is sometimes, the better. When there are big changes between releases, you should consider whether your technical architecture is old

2. What is the purpose of our project migration and upgrade — framework activity and project life cycle

3. On the importance of decentralization in projects — Good project specifications and decentralization can make the project life cycle longer. Reduce ancestral code

I. Version analysis

First you must have the initial version of Vue Li2 and a project demo of Vue Li3 and 4 on your computer. The first thing you have to do is distinguish between the two.

Personal summary version analysis:

1. Static resource files are categorized uniformly. Cli3 starts following PLULIC, but 2 is static and the two behaviors are consistent

2, Everyone uses SRC as the development directory, so there is no problem, just copy it

3, Webpack configuration difference, very huge, CLI2 for build and config mode, completely webpack directory format. However, after CLI3, the build directory is a separate NPM package, and all configuration is taken over by vue.config.js

4. Package. json is very different, cli3 is simplified, NPM package is highly condensed, cli2 is very ugly and cumbersome

5. Index. HTML is also different, but copy it yourself

6. Check the configuration of esLint, Babel, etc in the root directory

Ii. Project analysis

Migration objective 1: after the project migration, there are no major bugs, the interface runs, and the files report no errors

Release analysis was done above, mainly to see how different your current project will be from your old project. Here is the project analysis

1. You need to repeatedly compare the folders of config and bulid to see what optimization and configuration have been done before, which will affect the project. Generally, config will affect the operation of the project, while build is mostly the optimization part. The key is to figure out all the inconsistencies with the original CLI2. All the inconsistencies you need to implement in vue.config.js

Eslint, Babel and other configurations for analysis, generally copy and transplant on the line

3. Analyze your package.json section and find any inconsistencies in CLI2

Three, migration begins

1. Prepare a new VUE project for cli4 initials. project creation usually includes ESLint, Babel, non-TS, etc. How should you create the basic project you need based on the above steps

2. Copy the SRC file directly

3. The INDEX. HTML part and static part are included in plulic. The biggest fear here is that someone uses a relative path to import static files. No, that would be great

4, NPM package note version of the case, into the new VUE project, version is important. Note Specify the version install

5. Discard all optimization parts of Webpack and configure the configuration in bilud and config into vue.config.js

At this point, you can actually start the project, and if there are no major problems then the migration is basically complete. And then there’s the catch

Why is decentralization not mentioned

It’s not that I didn’t mention it, but it’s in every aspect of the project

For example:

1. Vuecli2 to CLI3 has been upgraded. The configuration file is independent into NPM package, and the config file is removed

SRC directory and public directory are more standardized

3. Secondary encapsulation of AXIOS in the project

4. Packaging of various functions

……………………………………

The bottom line is that if your project is clearly structured and separated, then your project will be iterative, maintainable, and have a longer life cycle, at least two years longer.

How to select the project

As an aside, in fact, the above is the general upgrade of THE VUE project in my previous company. And successfully run online, the optimization effect is good. And I was able to upgrade in a no-network environment. This is the core of my departure. I found I couldn’t stand the environment. I’m the one chasing new things too much.

After looking for a job for a month there is no good company. Alas! Now the company, I also have no choice. But I like the office environment

Back to business:

1. How do you, as the project leader, select your technical framework

Personal points: Popular, active community, well-documented, easy to get started, guaranteed maintainable and upgradable project in the next 3 years.

2. Why is Vue more popular?

React was good because vue was easy to get started with, but it was hard, so Vue came from behind

3. Why ts is so popular and needs to be learned, but why is it seldom applied in the project

Because you can’t hire people, because in practice you end up with a project that is heir-code

4, as the project leader, are you still pursuing your code without comments, variable names are the behavior of comments

All I can say is, stupid. If you’re worried that the person behind you is going to take your job and replace you, you don’t think about why you can be replaced.

5. For example, there are many small application frameworks, but the popular ones are UniApp and Taro. Mpvue, MPX, wepy, etc

Choose taro, choose uniAPP because hot, and use people are really very much, Wepy is the official maintenance, at least say small program unlike, Wepy die. How about mpVue, MPX?

It’s not that I don’t choose niche frameworks, but if you can’t guarantee that the framework is maintainable, iterable, or life-cycle. So please do not choose, or pit.

It is said that big companies come from small companies. But a big company or a small company, which would you choose?

There will also be a blog post I recently wrote about migrating the Wepy project to UniApp. Some people call me stupid? So what is the purpose of migration? I’ll give my opinion next time