Implement a CLI tool with Node

preface

Before starting the tutorial, let’s use the 5W method to get a sense of the tone of this article.

What

CLI is short for Command-line Interface, or in code slang, the command line interface. It has a good gay friend called GUIGraphical User Interface. The difference is your imagination.

Why

Let’s start with three soul questions: Why do we develop CLI when we have a convenient and intuitive GUI? Why build your own wheels when you already have open source CLI tools for most of the functional requirements you can think of? Obviously can’t think of the third question, why must gather together a soul three questions? To load B, to load B, to load B.

Who,When,Where

Now LET me lead you in putting on a little X here.

PS: In view of the length of the article, you can first look at the source code, combined with the source git log to see the article.

Project depend on

Let’s start with an overview of the dependency libraries we will use in this tutorial.

Babel: This tutorial uses the latest JS syntax. You need to use Babel to convert your code to a backward-compatible JS syntax.

Commitizen: Used to regulate our commit message.

Husky: Git hooks tool that works with Lint-staged and Eslint to do the shy thing before your code commits.

Lint-staged: A tool for filtering out Git code staged files (files added by Git).

Eslint: code checking tool, now also does code formatting.

Initialize the project

Don’t say anything, just open your Github and create a new project, skeleton-project-Generator.

Here complex wordy many sentences, do not want to see can skip this paragraph, does not affect the development. (really wrote a lot at the beginning, but in the end turned to judge to find long, just deleted) probably means, to do more projects and each project has the same part, every time is by replicating the best practices of the common part of creating the project, feel very tired, so I want to maintain a project template project, Creating a project from a project template is also a bit repetitive, so I wrote this CLI tool again to be lazy, I don’t know if I’m clear…

Open up a command line terminal of your choice (I recommend the obtrusive Cmder) and git Clone with the project we created.

Once the project is locally cloned, open it with your code editing tool (Vscode is recommended; I’ll base some of the following actions on Vscode).

Configuration EditorConfig

To ensure that the project has a consistent coding style across different editors or ides when multiple people collaborate, we use EditorConfig for constraints. First we will install the EditorConfig for VS Code plugin and enable it. Then we will add a new file in the project root directory:.editorConfig

# editorconfig.org
root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

[Makefile]
indent_style = tab

Copy the code

You can either use a GUI tool like Sourcetree or use the CLI tool that comes with Git. I won’t write down the specific orders, otherwise I’ll go too far off topic.

npm init

We use the NPM init command to initialize a Nodejs project.

$skeleton-project-generator(main -> origin): npm init
Copy the code

Follow the command line prompt and enter the corresponding value.

Git to commit. Here is a suggestion, try to make our Git submission granular, do not modify a lot of things, one-time submission, try to do one thing or a kind of thing, so that you find bugs later, and do some other operations will be very helpful.

Configuration Commitizen

We’ve done two Git commits before, but you’ll notice that our Commit Message is pretty random, and once we get more git commits, we’ll find ourselves digging holes again. A clear, concise, and normative Commit Message will be of great help for future code reviews, information look-up, version rollback, and so on.

Commitizen is a tool for standardizing git submissions. (Please refer to the document for details, we will use it directly below)

Install dependencies first:

$skeleton-project-generator: npm install --save-dev commitizen
$skeleton-project-generator: npx commitizen init cz-conventional-changelog --save-dev --save-exact
Copy the code

After executing the command, Commitizen automatically generates configuration information in our package.json file:

 "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"}}Copy the code

Let’s add a script directive to package.json:

  "scripts": {
    "commit": "cz"
  },
Copy the code

Add all the changes we just made in our project to the staging area via git add or Sourcetree and run the following command:

 $skeleton-project-generator:npm run commit
Copy the code

Then follow the prompt, enter the corresponding value is OK.

Configuring NPMRC (negligible)

I don’t know if you have noticed that a package-lock.json file was added to the project after our recent operation. I have not experienced the specific benefits of package-lock.json, but I often encounter some disgusting parts. The purpose of this section is to kill it, kill it, kill it. If you love it, you can ignore this section. It doesn’t matter.

To kill it, create a new file in the root directory.

package-lock=false
Copy the code

Then delete the package-lock.josn file and it’s OK.

Submit it, slut year! (Git triple connect,git add, NPM run commit,git push)

Configure the Babel

In this project, we will use the latest JS syntax, which nodeJS may not support, so we need to use Babel. As a tool chain, Babel can convert the code we write using the latest JS syntax into backward compatible JS syntax. To be able to run in current and older Versions of Node environments (or other environments). No more words, on talent:

$skeleton-project-generator:$ npm install --save-dev @babel/core @babel/cli @babel/preset-env @babel/plugin-transform-runtime @babel/plugin-transform-async-to-generator @babel/plugin-syntax-dynamic-import

Copy the code

Add babel.config.json (Babel V7.8.0 or later) file to the root directory:

{
    "presets": [
        "@babel/preset-env"]."plugins": [
        "@babel/plugin-transform-runtime"."@babel/plugin-transform-async-to-generator"."@babel/plugin-syntax-dynamic-import"]}Copy the code

Let’s add a script directive to package.json:

  "scripts": {
    "build": "babel src -d dist"
  },
Copy the code

Running this command compiles all the code in the SRC directory, which is our source directory, to the dist directory, which we then create. The dist directory and all the files in it are automatically generated by Babel after we execute the command.

We create the SRC directory under the root directory and create an index.js file:

import Os from 'os';
console.log(Os.cpus);
Copy the code

If we execute our code directly, let’s see what happens:

$skeleton-project-generator:node ./src/index.js
Copy the code

SyntaxError: Cannot use import statement outside a module

It’s Babel show time!

$Skeleton-project-generator: NPM run build & node./dist/index.js
Copy the code

Execute NPM run build first, and then execute node./dist/index.js.

Well done! We can see that the console is printing out CPU information, which means we’re on to something!

Git three even!

Configuration Eslint

As we get deeper into the logic of code development, our code may have more or less low-level errors, and Eslint is designed to help us correct these low-level errors during development.

Eslint is a code-checking tool that recognizes ECMAScript and reports on rules to avoid low-level errors and unify code styles.

Install dependencies first:

$Skeleton-project-generator: NPM I --save-dev eslint eslint-config-airbnb-base eslint-plugin-import
Copy the code

Add.eslintrc file to the root directory:

{
  "extends": "airbnb-base"
}
Copy the code

Install the Vscode plugin ESLint and enable it.

SRC /index.js: SRC /index.js: SRC /index.js: SRC /index.js: SRC /index.js

We can either install prompts for individual changes, or fix them with the one-click fix that comes with the plug-in we just installed.

Git three even!