PretTier to format WXSS with one click

This article will incorporate tools like ESLint, Prettier, husky, lint-stage, gulp.js, etc., to make the project one-key and reduce the time wasted on formatting, code checks, etc., because there is so much to learn about the big front end, and if we don’t learn to “slacken”, we will fall further behind.

The sample Demo for this series is here? Making: wechat_applet_demo.

It is divided into three articles:

• PretTier to format WXSS with one click
• PretTier to format WXSS with one click
• PretTier to format WXSS with one click

The previous article showed you how to format a WXSS file with one click.

This article introduces the use of Git Hooks to automatically execute the ESLint and Prettier commands to ensure that the code you commit is not ugly.

Git hooks

Git provides hooks that trigger custom scripts when certain important actions occur.

When you execute git init to initialize a Git repository, Git places sample scripts (Shell scripts) in the.git/hooks directory by default. These sample scripts all end with.sample, so if you want to enable them, you’ll have to remove the suffix first.

To activate the hook script, place a properly named (without an extension) executable file in the.git/hooks directory. This way, it can be called by Git.

Two, commonly used hooks

• pre-commit

This hook runs before typing the commit information. It is used to check snapshots that are about to be submitted, for example, to check for omissions, to ensure that tests run, and to verify code. If the hook exits with a non-zero value, Git will abort the commit, but you can bypass this process by using Git commit –no-verify. You can use this hook to check if the code style is consistent, if trailing whitespace characters exist, or if the documentation for the new method is appropriate, and so on.

Third, husky

Husky is a tool for adding hooks to Git clients. When it is installed in its repository, it automatically adds hooks to. Git /hooks. The implementation performs a series of guarantees during the pre-commit phase to ensure that each commit is correct.

Of course, it’s important to make sure that the commands you execute during the pre-commit phase are not too slow. Waiting a long time for each commit is not a good experience.

1. The installation of NPM – run – all

It is used to execute NPM script scripts synchronously or in parallel.

$yarn add --dev [email protected]

This is done by combining the previous NPM script and using NPM -run-all to string together several commands.

{
  "scripts": {
    "format:all": "npm-run-all -p prettier:wxss:acss prettier:fix -s eslint:fix"
  }
}

The prettier: WXSS :acss and prettier:fix commands are first executed in parallel, and then the eslint:fix command is executed later.

• npm-run-all -pRepresents parallel operations.
• npm-run-all -sRepresents operations in order.
• It also provides a shortened version of the API for the above two commands, respectivelyrun-p,run-s.

Because the files that match prettier: WXSS :acss and prettier:fix do not overlap, the operation can be done in parallel. PretTier formatting first and ESLint checking later, because the two are in conflict.

While we could introduce plugins in.eslintrc.js to configure it to report errors when Prettier rules don’t conform to ESLint rules, it doesn’t solve our pain point and requires us to fix it manually.

Also, it is always possible to execute ESLint first and then Prettier. So I decided to put the script together and make it work the way we wanted it to: when there was a conflict between the two, we used ESLint’s rules.

The full script is as follows:

{
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "eslint": "eslint ./ --ext .js",
    "eslint:fix": "eslint --fix ./ --ext .js",
    "prettier:fix": "prettier --config .prettierrc.js --write './**/*.{js,css,less,scss,json}'",
    "prettier:wxss": "gulp wxss",
    "prettier:acss": "gulp acss",
    "prettier:wxss:acss": "gulp all",
    "format:all": "npm-run-all -p prettier:wxss:acss prettier:fix -s eslint:fix"
  }
}

2. Install the husky

$yarn add --dev [email protected]

Add configuration to package.json to make it format when git commit-m ‘XXX’ code is committed to ensure that the code we commit is not ugly.

If an error occurs during the process (such as an ESLint failure), the COMMIT operation will be stopped, i.e. pre-COMMIT returns a non-zero result to exit.

It can be ignored with git commit –no-verify.

// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "yarn run format:all"
    }
  }
}

3. See the effect

We modify a file at random and then commit it. And if you look at it, you can see that it works as expected. There we go.

Fourth, lint – staged

Looking at the results above, everything seems to be going well. But it’s not over…

As we can see from the figure above, we only submitted one file change, but it scanned all the files. There is an experiential problem here.

If we have N files, then every time wegit commitGoing through all the files at once resulted in a very bad experience, a slow process, and obviously not what we wanted.

So what’s the solution? We need to use it, right? Lint – staged.

$yarn add --dev [email protected]

Starting with the V3.1 release, there are a number of different ways to configure this without going into detail here.

Create a.lintstagedrc.js configuration file in the project root directory and specify it as –config or -c.

// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged --config .lintstagedrc.js"
    }
  }
}

// .lintstagedrc.js const path = require('path') module.exports = { '*.js': ['prettier --config .prettierrc.js --write', 'eslint --fix --ext .js'], '*.json': 'prettier --config .prettierrc.js --write', '*.wxss': // const CWD = process.cwd() // const relativePaths = Absolutepaths. Map (File = Absolutepaths path.relative(cwd, file)) // return `gulp wxss --path ${relativePaths.join(' ')}` return 'gulp wxss' }, '*.acss': 'gulp acss' }

Note that we do not pass the path as an argument when the command is invoked. This is important because lint-staged will do this for us.

Lint-staged is used in the GLOB mode. From the above configuration, perform the corresponding action by matching the different file types.

* For instructions on lint-staged use, please check the official passageway documentation or the thinner version of this article, which I will not go into detail about.

I don’t know if anyone is curious, up here
lint-stagedIn the configuration file, I’m matching
.wxssFile in the form of a function.

In fact, there is a problem that has not been solved here, that is, in submission.wxssWhen staging a file, this is not the only processing.wxssInstead of files, the project will be owned.wxssFiles (including those not committed to staging area.wxssFile).

As I explained earlier, Prettier does not have a parser to handle files with the.wxss extension, so we use gulp.js to do so by converting the file type. The corresponding Gulp task matches all.wxss files in the current project. The Gulp. Dest (__dirname) is exported to the source file as normal.

2️ section follows the idea of lint-staged and only handles submitted staging files. This means that we should pass a file path to the gulp WXSS task and then modify the wxsrettier task to match either all or individual or multiple.wxss files instead of all. Then I tried several methods, but none of them worked.

3️ I tramp pit train of thought is roughly: Pass one or more path parameters to gulp WXSS (config file comments above), get NPM script parameters through process.argv, and then process the parameters in the wxssPrettier task by passing an array to gulp.src(). And I think I’m on the right track. But the reality is that when gulp.dest() is exported to the wrong path, all the.wxss files are exported to the project root, which is obviously not what we want.

4️ l I haven’t found a better solution yet, welcome your comments.

Because of this problem, I think my wechat_applet_demo is not perfect (I have obsessive compulsive disorder). If there is a solution in the future, I will come back to update it.

There’s a solution. Check it out
finale.

At this point

This is almost the end of the story, but it is possible to add a Commit Message specification, because a clear Commit specification will make it clear what the purpose of the code Commit is or what specific problem it is addressing. By far the most widely used is the Angular specification, which is reasonable and systematic, and comes with tools. Check out the Git Commit specification guide in this article.

If you have any inadequacies, please let me know.

The end.