A preliminary study of VuePress

In the previous article, a simple analysis of VuePress’s source code was carried out and we learned that:

  • Vuepress package is responsible for CLI command registration and processing. @vuepress contains the main logical processing part
  • Whether it isvuepress dev docsorvuepress build docsCreate createApp and parse process
  • The processS process can be divided into five stages, which are:
    • 1) Configure parsing & template loading
    • 2) Plug-in enqueue & initialization
    • 3) Markdown related processing
    • 4) Source file collection
    • 5) Plug-in execution, and the final generation of temporary files

But in the next stage, vuepress Dev docs and Vuepress Build Docs start to get stuck. The analysis of the two most important execution processes first helps us to get a general picture of the project and then to analyze implementation details from there.

Dev execution process

Those of you who have used VuePress to create a website have seen the results of running VuePress Dev Docs:

The previous [WDS] shows that within VuePress’s VuePress dev docs it uses webpack-dev-server capabilities to start local servers and support debugging

To verify this, let’s look at the logic of Vuepress Dev Docs:

After creating the instance with createApp and waiting for the resource processing process to complete, the dev logic begins:

After entering dev, perform the following three steps:

  • Step 1. Build an instance DevProcess from the DevProcess class
  • Step 2. Next call process with the instance devProcess (different from process of the previous App class)
  • Step 3. Finally, listen for file changes and start a local server on the specified port

The first step, as you can see from the constructor, is a simple context-assignment, while the second step’s process contains a lot more:

The above three watches are responsible for monitoring changes. The setupDebugTip in the middle is for easy debugging by users. Finally, after processing port and host, the Webpack configuration is generated and the webpackConfig attribute of the instance is put in.

Step 2: Set up the listener and build the Webpack configuration. Step 3: Start the local server

For the above method can refer to the Demo website link: www.webpackjs.com/guides/hot-…

When using webpack-dev-server in NodeJS, you should write the configuration to addDevServerEntrypoints(config, options). The first parameter config is webpack configuration. The second parameter, Options, is the value object we normally write to the devServer field in webpack.config.js. The rest of the compilation and server startup is basically the same as the Demo on the official website without further elaboration.

The execution of vuepress Dev Docs has been briefly covered here: After the generic instance creation createApp and parsing process, enter the dev process, set up to watch the file changes & build the Webpack configuration, and finally start a local server with webpack-dev-server.

Ii. Build execution process

Let’s continue with the vuepress Build Docs execution process. First let’s look at the results of executing Vuepress Build Docs:

As you can see, after the app.process, the Client and Server compilations take place, followed by a “static HTML rendering” that eventually generates the static resources into the target folder.

The reason why the Client and Server compile records, according to the SSR based understanding should be:

  • A server-side rendering code is generated to generate HTML
  • A corresponding client code is generated to activate the HTML generated by the server to support responsiveness

The following “static HTML rendering” is based on VuePress’s feature of generating static web pages through fixed Markdown files. It can be understood that because the web pages are completely static, they do not need to be generated by the server every time, but directly generate a fixed “server SIDE HTML” when packaging.

Rendered =” True “; Rendered =” Rendered “; Rendered =” Rendered “; rendered=” Rendered “; rendered=” Rendered “; rendered=” Rendered “; rendered=” Rendered “; rendered=” Rendered “; rendered=” Rendered “; rendered=” Rendered “; rendered=” Rendered “; rendered=” Rendered” Therefore, the above point of view is proved

OK above from the execution log and generated results to reverse the following execution process:

  • Step 1. Compile the server renderer & client activator
  • Step 2. Execute the server renderer -> generate the server rendered HTML

That we take a look at what is the relevant code, we find the location of the build method (@ vuepress/core/lib/node/App. Js) :

You can see that once the instance is created based on BuildProcess, it is really done in two steps: Process and Render. Since we have seen dev’s source code before, we can guess that the process method should only be used to build Webpack configuration and prepare other configurations

1. The analysis of the process

Is the same as the dev are made to start & resolveCacheLoaderOptions method made the end, construct a Webpack configuration prepareWebpackConfig method among little but build this side to a pile of monitoring and debugging process, The only thing you do is create the resulting directory.

2. Render analysis

Next we go to the Render method, and a quick scan reveals that each stage has a brief comment, roughly the same as our inverted execution process. Wait (‘Rendering static HTML… ‘) this line is printed as a dividing line, dividing the program into two parts.

1) Step 1: Compile the server renderer & client activator

Here we have masked all the code in the Render method except compile(), rerun the Vuepress build docs, and see that a temporary Mainfest folder has been generated

Think of the official flow chart of Vue SSR. Yes, these are the two bundles on the far right:

Now it’s time to read the bundle and get ready to create a bundle Render for the next step of rendering the HTML page:

2) Step 2: Execute server renderer -> generate server rendered HTML

When the Bundle Render has been created and you want to generate static pages, RenderToString has the ability to automatically execute the function exported by the “application instance created by the bundle” (passing the context as an argument) and then render it). Now back to the code logic:

RenderPage gets the HTML string after rendering and writes it to the target file:

This completes the build process

Now you can go to the doc/.vuepress/dist directory and run http-server to start a server

View the request page, although it is started with static resources, but still in the form of SSR ~

summary

VuePress’s dev and Build processes start with createApp and process, but the dev and build processes end differently.

First they get different Webpack configurations through different conditional judgments, and then:

  • Dev creates a local debug server based on webpack-dev-server
  • Build reads the configuration of Client and Server through Webpack, packages two bundles, and then completes the generation of HTML in advance with bundle render. Achieve the purpose of directly generating usable SSR HTML (with SEO optimization and first-screen loading optimization features).

The journey is continuing, years (°, °) Blue ✿