Front-end engineering from the perspective of business component library

In the past six months, most of my energy has been on the business component library, and in the development and maintenance of the business component library, another main thing I do is the complete engineering process of the component library (or material assets).

This article is not a teaching article, it is only a summary of the running account that has been worked on in the past six months, and it is also a memorandum for myself, and because it is an internal asset of the company, the source code and screenshots cannot be posted in many places. Interested parties are welcome to discuss.

Talking about front-end engineering

In my opinion, front-end engineering refers to the precipitation of part of the tedious and repetitive work in the usual workflow in the form of tools, thereby reducing the repetitive work of mechanization by developers. The tools here are not limited to local project scripts, cloud services, etc. For example, we use CRA to initialize engineering projects, package and build projects through Webpack / Vite, and launch front-end projects through cloud services, etc.

From my personal experience, all simple repetitive mechanical labor involved in development can be significantly improved more or less through engineering capabilities.

Front-end engineering is just as numerous as performance optimization, and the main entry point of this article is the automation in front-end engineering, using the ability of engineering automation to penetrate the initialization of the material system -> development -> construction -> the entire life cycle of going online, rejecting everything Not efficient.

Looking at the whole process of engineering from the perspective of life cycle

initialization phase

For the initialization phase, the material side provides an initialization template for components/blocks to facilitate the rapid initialization of components/blocks.

development stage

As a display site for the material system, it includes multi-dimensional front-end assets such as components, blocks, solutions, and tool sets. Therefore, it adopts the MutiRepo architecture and completely deviates from the traditional npm link package development model.

• On the component side & material side, after the development script is started, the source code changes are monitored in real time and synchronized to the site's cache directory.

• On the site side, add the .dev directory as the cache directory for local development, and alias the component library to the .dev development directory in dev mode. And with the support of Vite, we will continue to improve the development experience.

  • During the cold start phase, the local development script pre-checks the validity of the .dev directory. If it is invalid, it copies the component source code under node_modules in full as a temporary cache file.
  • During the hot update phase, the devServer monitors the real-time hot update for changes in the .dev directory files.

For more local development, check out my previous article: Speed up your productivity

build phase

The material-side construction phase is only to build and generate ESM packages and ES5 packages. Here we mainly talk about what to do during site-side construction.

Generate documentation

Since the component library is completely developed through ts + comments that conform to the jsdoc specification, we pass the script in the documentation step:

• Scan all component catalogs;
• Generate document AST JSON by parsing component type declarations and comments through typedoc;

The site then parses the document AST JSON at runtime and generates the document.

build dependencies

Another function of our display site is to display the atomic components that the current business components depend on and generate a dependency graph. Similar to the logic of generating documents, we will scan the business component directory through the script to analyze the AST of the business components to generate the dependency JSON, and the site will dynamically loads JSON when is running to show dependency Sanchi diagrams.

Generate component basic information

The metadata of the component already exists in the component source code, so there is no need for secondary maintenance on the site side. Therefore, while generating the dependencies, we parse the metadata in the component through AST, and generate the basic information of the component JSON. The site will dynamically load JSON at runtime to display the component name, component designer, component description, component design draft and other information.

Sync block code

The previous article from the business component library to see the front-end material ecology shared that our blocks are stored in the form of source code, so it is just needed to pull the latest source code in real time during construction. Therefore, we implemented the following functions through engineering scripts :

• For blocks:

  • Read the block container directory;
  • Analyze block variant dependencies under Container;
  • Pull main/subblocks through tools;
  • The code is loaded when the site is running;

• For solution:

  • Read the material.json file under the solution to obtain solution dependencies;
  • Pull main/subblocks through tools;
  • The code is loaded when the site is running;

Upload Demo

The demo preview implementation of our business component library is different from other component libraries. Other component libraries write Demo on markdown during development, and parse markdown into HTML during compilation. Our business component library Demo will be stored in the form of tsx source code in the site test, uploaded to the CDN during construction, and loaded with real-time preview of CDN source code resources during runtime.

release stage

For releases from material to site, we have a strict chain release process:

First of all, for components and blocks, we automate the release of NPM and CDN through the automated release tool materials-tools-release, which reduces the cost of code merging, branch checking, version detection, automated scripting, release and other steps and reduces the risk of errors.

Previous releases (using the component library as an example):

• This is a norm, nothing to say;
• You may have forgotten this step;
• You may also forget this step;
• You may also forget this step;
• You may also forget this step;
• This step may be the one you forget the most, but you can make up for it with the prepublish hook;
• This step may be the only one you will perform;
• I think you may not know what this is;

Current releases:

Fewer steps, fewer mistakes.

The last is site deployment.

tool precipitation

In the process, we have precipitated a set of tools that serve the common component library scenario.

materials-tools-ast

Based on babel, it has done secondary encapsulation, which can easily obtain the ability to import and export files. Analyzing Component Derivatives

materials-tools-cli

material-tools-cli mainly provides two parts of capabilities: material pull kernel + material pull cli tool. Among them, the kernel serves the cli tool and the vscode plugin mainly do the following:

• Identify whether the material exists, identify whether there is a material with the same name in the current directory;
• Pull material from CDN according to material name;
• Merge dependencies and prompt according to the pulled material dependencies;

materials-tools-utils

The tool functions commonly used in the process of engineering script development are encapsulated:

• file.ts: file operations;
• log.ts: log output;
• command.ts: command line execution operation;

materials-tools-release

Automated release tools that reduce the cost and risk of errors for steps such as code merging, branch persistence, version detection, automated scripts, releases, and more.

Automated publishing of toolsets

The toolset adopts the MonoRepo architecture based on lerna, but lerna does not meet some of our demands (for example, we have many demands for unified custom npm hooks), so we do a secondary encapsulation based on lerna:

• Get updated package version information with release through lerna changed;
• Update the package version to be released through lerna version;
• Sort according to the configuration file, for example, a depends on b, and b depends on c, then the sorting is c -> b -> a;
• Execute in sequence according to the sorted list and execute in sequence according to the execution order of custom hooks;
• release;