A Shang, Zhou Zebin, Gao Zhiheng

Objectives of scaffolding

Unify: Unify module input and output

  • Ability to quickly generate catalog templates (project scaffolding) for new projects of its own.

  • Improve development efficiency and reduce repetitive development of components with the same function (module scaffolding).

Standardization: establish model standards and unify cognition

  • Multiple teams achieve uniform standardization, reducing the cost of understanding due to different project specifications and standards.

Automation: Reduce personnel involvement to reduce costs and improve delivery efficiency

  • Improve project construction efficiency and reduce packaging dependency.

Erection of scaffolding

The team’s current technology stack mainly uses Vue, so the scaffolding is also built on the basis of Vue CLI.

1, global installation vuE-CLI

After installing vue-CLI globally, you can use the vue command from the command line. Those familiar with vuE-CLI know that you need to use vue init webpack XXX to quickly generate a template project before starting a new project.

However, in the actual development process, we often adjust the directory structure according to the needs of the team or the business, and develop project templates that conform to the business logic.

2. Create a custom project directory structure template

– First we need to know which command parameters vue init supports.

Vue init -c can clone Git remote repository code locally.

Our project directory structure here mainly refers to the official Webpack template of Vue.

As shown in figure:

– Modify the project directory structure of template and upload it to the remote repository.

All we had to do was clone the Vuejs-Templates/Webpack project locally, change the directory structure under the Template folder to our own directory structure, encapsulate the internal common logic, and upload the modified code to our Git remote repository.

Use of scaffolding

At present, the team has built three kinds of scaffolding based on VUE-CLI for different business scenarios:

  • Project scaffolding

  • Background scaffolding

  • Modular scaffolding

1. Project scaffolding

Project scaffolding is used to quickly create a project that contains the base VUE and some of the team’s own components, such as edu-axios (introduced via galaxyDependencies, described later), as well as the integration of webpack plug-ins that rely on internal components. Used to resolve dependencies.

2. Background scaffolding

Background scaffolding is based on project scaffolding, mainly used to quickly create a background management system project (including the login interface, left menu structure, the right side of the corresponding content display, etc.).

The usage is as follows:

The directory structure generated by my-project is as follows:

After yarn install, use Yarn Dev to start the project. The browser automatically opens http://localhost:9090/, and the following page is displayed:

– http://localhost:9090/#/login Login page

– the http://localhost:9090/#/index home page

Now a team in line with the standards of the background management system project directory structure to create completed, users do not need to care about the construction process of the project structure, only need to concentrate on writing business logic.

3. Module scaffolding

Module scaffolding is primarily used to rapidly develop common functional components, each of which is a separate project.

A WebPack plug-in for dependencies on internal components is integrated into the project to resolve dependencies. Build logic is provided to generate the depends. Map. json file and the actual file that needs to be uploaded for the composite Galaxy dependencies.

Tip: The module project created through the module scaffolding will be packaged and compiled to generate modules conforming to UMD specifications, and a depends. Map. json file will be generated during the packaging and compilation process (the module dependency analysis of the current project will contain all packaged products, CSS, JS, And externals on which the current module depends, etc.), for example:

Later, Jenkins will upload the depends. Map. json and the packaged products to the CDN respectively when deploying Jenkins automatically.

(The only thing you need to know is that it will generate depends. Map. json in the process of packaging and compiling, and the specific effect will be mentioned in the following [practice of Webpack externals in scaffolding].)

The usage is as follows:

The directory structure of the project generated by my-Component is as follows:

The consumer can then focus on encapsulating functional components without having to repeatedly create the same format directory structure.

Webpack externals in scaffolding practice

Let’s first understand what webpack externals is.

Externals prevents import packages from being packaged into a JS file at build time and instead fetching these extension dependencies externally at run time.

For details, see the Webpack documentation for externals.

We introduced all our modules in the form of externals, which improved the efficiency of construction.

How exactly is it introduced?

Each scaffold project integrates galaxyDependencies in package.json, which is an internal dependency component. During project construction, Webpack gets a dependency of the corresponding version of Depends. It then asynchronously requests it and resolves its dependencies, inserting it into the externals of the current project, which we’ll use as an example in eduAxios.

The following describes exactly what code is included in the scaffolding project.

Loading of the galaxy. Config. Js

There is a galaxy.config.js file in the scaffold project directory structure (Template), which presets the build configuration as follows:

{{name}} is a variable that was dynamically injected during project creation using scaffolding and represents the current project name, as in package.json:

When creating the project with vue init -c true git.lagou.com:fe-formwork/edu-component my-component At the command line, we are prompted to enter the Project name, Project description, Author, and so on for the current Project.

These input values are automatically injected into the corresponding {{name}}, {{description}}, {{author}} template variables in package.json and galaxy.config.js.

Adding module dependencies

When our project/module relies on other custom modules, there are two ways to introduce it:

Here, take the eduAxiosComponent module as an example. The eduAxiosComponent is wrapped based on AXIos, adding a layer of interception for its own use, which can be used for unified interception.

1. Add the module name and version number to the package.json galaxyDependencies object.

2. Launch the project. During launch, all dependencies of eduAxiosComponent version 1.0.1 (including its own packaging and its current dependencies) are inserted into externals using the WebPack plugin to analyze the dependencies. Since modules are packaged using umD, they can be accessed using import or window, as follows:

How to analyze dependencies

The configuration objects exposed in galaxy.config.js are referenced in vue.config.js, and the vue.config.js file is automatically loaded by @vue/ CLI-service when the project is compiled.

The vue.config.js code is as follows:

A WebPack custom plugin is used here: GalaxyFetchDependsplugin.

Galaxyfetchdependsplugin does the following before WebPack builds (beforeCompile hooks) :

  • Request depends.map.json for all dependent modules specified in galaxyDependencies in package.json.

  • The module names from the requested Depends.map.json are injected into externals of the Webpack Compiler object as key-value pairs.

  • Merges dependent module resources with current WebPack-compiled resource files for de-duplication (currently, only duplicate strings are de-duplicated, and then repeat rules are specified, such as protocol, version, min-package-induced duplication, etc.).

  • Write the resources that the current project depends on to dist/depends.

  • Rewrite the templateParameters method of the webPackhtmlPlugin plugin to write all dependent resources into THE HTML.

Jenkins deployment

When deploying by Jenkins, the latest dist/depends. Map. json and packaged products will be uploaded to THE CDN each time. When other projects/modules reference the current module, they only need to follow the above steps to introduce it.

conclusion

Convenience brought

Project scaffolding and module scaffolding allow team developers to quickly create a project structure catalog before starting a new project or encapsulating a new module, reducing the cost of repeated construction, improving development efficiency, and unifying standards across teams.

Impact on services

Project scaffolding can quickly create a project structure directory that meets the team’s requirements when splitting the original bloated, unseparated, multi-project into separate projects. Developers can get started directly without more construction and understanding costs.

Module scaffolding can quickly create module project templates when the original project common modules are extracted and split. With the implementation of Webpack externals configuration in scaffolding, the compiled project has smaller volume, clearer dependency, more stable module version and more efficient construction.

Subsequent impact

Subsequently, the team will split the c-end and B-end projects one after another. The split projects will be completely separated from the front and back ends, which will be automatically deployed by Jenkins and mapped to the split projects by the front-end Nginx. The front-end scaffolding is a solid foundation for subsequent projects to be dismantled.