Why are we doing this?

In January, I published building Vue Component Libraries from 0, which is a Todo type article on building component libraries, including building, configuring, packaging, and publishing component libraries. As the front-end infrastructure is more and more perfect, we will produce more and more like the front of the library, and type more and more: component library, js, CSS, library every library needs to start from scratch to build configuration package release, this kind of repeated labor is obviously unreasonable, lazy, after all, is the first productive force, so have a good way to solve this problem? Therefore, I came up with the idea of Node Cli, which is simple to install and update, unified and standardized process, and has great potential to exploit subsequent functions. It replaces repetitive work and allows students in the front-end group to have more time to focus on coding.

The target

Figuring out the goal before you do it is a great way to avoid getting halfway through: Who am I? Where I am? What am I doing? Let’s take a look at the specific problems that we need to solve with the CLI. Here are a few examples of the problems I have encountered in my work:

1. Build products with regular compression: Library besides to be uploaded to the NPM, also need to be uploaded to the server for static resources of some old items directly through the label, introducing path need according to certain rules will build product compressed into a zip package uploaded (similar/lib/front/projectName/version/XXXX. The umd. Js), In this way, each project needs to have a set of logic for deleting zip packages before packaging and generating zip packages after packaging.
2. Version control:Build Vue component library for automatic version management from 0I introduced it to you in the projectnpm versionVersioning projects, making a copy of each one, and I couldn’t bear to copy the second one and had to pull it out.
3. Release configuration: Each project requires a release configuration for the release platform to execute. It may be necessary to manually change the release number in order to avoid release failures.
4. Tag: we upload static resource server is able to overwrite the file, which has both advantages and disadvantages, the advantage is that the library release efficiency is very high, the disadvantage is not enough security, need a mechanism to avoid risks, for us to automatically tag, less than or equal to the tag version of the library to upgrade the version of the proof.
5. Initialize libraries and add template components: Every time you build a library, you have to configure WebPack, project structure, tsconfig, Lint, etc from scratch. Although you can copy existing libraries and do pruning, there is no CLI that generates a copy directly.

To summarize, the Node Cli needs to solve the following problems: compression build artifacts, automated version control, pulling standard release configurations, automatic tagging, and downloading library or component templates.

These are the problems I have encountered, and it’s best to use your own business scenario to see if Node Cli can help you eliminate some of the repetitive tasks.

Open to

Foundation frame construction

The principle of the Node Cli is to use NPM i-g cli-name to package the installation to the global node_modules. After the command is executed on the Cli, the system will execute the corresponding script according to the Node environment variables.

Add the following to the PACKage. json of the CLI project:

{..."bin": {
        "mycli": "./bin/mycli.js"}... }Copy the code

So when other students install globally, you can directly use mycli command to execute mycli.js script.

We can use NPM link to link the project to the package folder for local development, which makes it easy to debug without having to rebuild every time.

Next take a look at mycli.js and add #! To the top of the file. The /usr/bin/env node is designed to solve the problem that different users have different paths to the node, allowing the system to dynamically find nodes to execute the script.

We’re going to rely on some excellent third-party packages here, and I’m going to go with Commander. Js, which is the complete solution to the Node.js command line interface

#! /usr/bin/env node

const { program } = require('commander')

const { resolve } = require('path')

const res = (command) = > resolve(__dirname, '.. /src/', command) // Read the script path

const version = require('.. /package.json').version

program.version(version, '-v, --version') Run mycli -v or mycli --version to output the current version number

program.command('init').description('init lib').action((a)= > { // Init script description and execution
    require(res('init'))
})

program.command('build').description('build lib').action((a)= > { // Describe and execute the build script
    require(res('build'))
})

program.command('release').description('release lib').action((a)= > { // Describe and execute the release script
    require(res('release'))
})

program.parse(process.argv) // Process the output parameters
Copy the code

Ok, now that the basic framework of the CLI is in place, the next step is to enrich its functionality.

Rich functionality

After the function is more and more, our cli itself may have large size code structure complex problems, then we can separate the function of the independent NPM package, introduced by cli these packages, pluggable solution can refer to cloud music front-end technical team of the article: the Node cli tool plug-in solution exploration (learn from bosses).

Among the problems mentioned above, I will use the following three scripts to solve them. I will mainly talk about how to implement each script. Students still need to implement scripts according to business needs, so there is still a lot of imagination.

1. Init: Download the library template or component template
2. Build: Compress build artifacts and automate version control
3. Release: pull standard release configuration, automatically tag

First, I recommend several third-party libraries to help us achieve better and faster functions:

init

Problem solved: Download library templates and download component templates

We can put the preset library template in our CLI repository, or put it in a special template repository, and then download it through the GitLab API. Before using the GitLab API, we need to go to the account Settings to get a private_token. Call API with this parameter to gitLab to do authentication, and then use API recursively read files in the GitLab warehouse, corresponding to write to the current directory, complete the library template download, during which you can use ORA to get some chrysanthemum diagram, with Nod-emoji more whole a few green tick to increase the user experience.

build

Problem solved: compact build artifacts, automated version control

Using Inquirer to interact with the user, you can ask the user: Which NPM Version upgrade strategy is used? What type of project is packaged? The name of the library? Multi-entry library selection entry file? Package the output path? Optional execution scripts?

Json (resolve(‘pathTo/package.json’))) to retrieve the name and version of the user’s project, which can be used as the default for inquirer questions. After all, every time the user input packaging experience is too bad, all the way back to spark with lightning is definitely the most cool. Since we can obtain the package.json of the user, we can do some conventional configuration. For example, the config.cli object in the package.json of the user is the parameter object specially used by the CLI for reading, and the user can write some customized configuration.

The solution I practice on projects is to use the project information obtained by inquirer to piece together vUE or Webpack packaging commands (the company mostly uses VUE), such as building the VUE component library, which will eventually be executed

npx vue-cli-service build --target lib --name name --dest path
Copy the code

The Webpack build executes

webpack --output-path path
Copy the code

The user’s configuration can be read from the convention config.cli on top of the basic build commands, for example adding the env parameter if the user needs to package different environments

After packaging according to customer’s package. Json information such as name, version, put the building products in/lib/front/projectName/version/XXXX. The umd. Js then by compressing compressed into a zip package

release

Problem solved: pull standard publishing configuration, automatic tag

Pull standard publishing configuration is similar to init in that you download a standard configuration and write it based on the user’s package.json.

Automatic tag: I provided an optional tag parameter for the release directive, which can be read by process.argv. After reading the tag parameter, use the GitLab API to tag the corresponding branch. Subsequent builds and releases can check the tag version and user package.json version first to remind users not to forget to upgrade the version.

.

There are many other functions that can be integrated into the CLI as long as the imagination is sufficient, the service needs are sufficient, and the redundant labor time can be saved.

conclusion

This article introduces the usage scenarios and basic framework construction of Node Cli, and provides the implementation ideas of several functions.

Mainly presented themselves in the front end construction company in the process problems and the solutions to solve the problem, not the best solution, and I hope you if you have a better plan to discuss, the solution is not necessarily every company every business and general, want to learn from classmates or proposal from the company’s business to make a suitable for your company’s cli.

My name is Suhangdev, welcome to communicate with me about front-end related topics, email [email protected], if the article is helpful to you, please like and support oh, thank you!