This article explains how to quickly create and implement code specifications in front end teams!! Dry stuff. Take the warehouse

The background,

A new department was replaced in September, which was not established for a long time. At that time, there was no unified code specification in the group (some projects used the specification, others did not, and there was no unified closure).

The team’s technical stack framework includes Vue, React, Taro, Nuxt, and Typescript, which is a bit miscellaneous. Combined with the possibility of extending other technical stacks in the department, we implemented a common code specification from 0-1

I have been using it for several months now, and the whole process is relatively smooth and fast, so I had time to share it recently

⚠️ this article will not talk about the basis of specific norms, but from the practical experience of how to formulate norms and landing norms

Second, why code specification

Don’t say… You know

If you don’t know much, give directions

Three, determine the scope of the specification

First, synchronize with the supervisor. The team needs a unified specification, and the supervisor is waiting for someone to do it

The first step is to gather the team’s technology stack and determine what the specification covers

The specification is sorted into three parts: ESLint, StyleLint and CommitLint. The analysis is as follows based on the actual situation of the team

  • ESLint: TypeScript used by teams. The framework uses Vue, React, Taro, and Nuxt
  • StyleLint: Less for team unity
  • CommitLint: Git code submission specifications

Of course, you also need to consider the technology stack that the team may extend to later to ensure that it is implementedscalability

4. Investigate the implementation plan of the industry

The following three schemes are commonly used

  1. The team creates a documented code specification that members write code to follow

    Relying on people to ensure the existence of code specifications is not reliable, and it requires people to review the code is not standard, which is low efficiency

  2. Directly use a mature specification in the industry, such as StyleLint official recommended specification stylelint-config-Standard or Stylelint-Order for CSS, ESLint recommended specification ESLint :recommended, etc

    A) Open source specifications often fail to meet team needs and have poor extensibility; B) Industry-provided specifications are independent (STYLint only provides CSS code specifications, ESLint only provides JavaScript specifications), are fragmented and can be costly and unreliable for specification initialization or upgrading (multiple steps per project require a human to perform)

  3. Develop team specification NPM packages based on StyleLint, ESLint, and use team specification libraries

    A) This solution solves the problem of poor scalability, but the problem (b) in point 2 still exists

V. Our technical proposal

The overall technical thinking diagram is shown below. There are three base packages: @JD /stylelint-config-selling, @JD/ESlint-config-selling, and @JD /commitlint-config-selling for Stylelint, ESLint, and CommitLi, respectively nt

  1. @jd/stylelint-config-sellingIncluding CSS, LESS, saas(not currently used by the team)
  2. @jd/eslint-config-sellingVue, React, Taro, Next, NUxT (not currently used by the team)… , as well as possible future extensions to ESLint plug-ins or parsers that require customization
  3. @jd/commitlint-config-sellingUsing Git

Provide a simple command-line tool to interactively initialize init or update the UPDATE specification

A few key points

1. Unified management package with LERNA

lernaJavaScript is a management tool used to manage JavaScript projects containing multiple packages. It is widely used in the industry

The project structure is shown below

Set the dependencies of the three base packages to production dependencies

As shown below, package@jd/eslint-config-sellingDependency packages are written in production dependencies, not development dependencies

Explain:Development dependency & Production dependency

  • Development depends on: For business projectsDon't downloadPackages in development dependencies, common industry specifications such asstandard,airbnbAll written in development dependencies
    • Disadvantages: Business works except installation@jd/eslint-config-sellingYou need to install the pre-installed dependency packages yourself, such aseslint, according to their choice of framework installation related to the pre-dependency package, such as the use of Vue need to be installedeslint-plugin-vue. High cost of operation and maintenance and upgrade
    • Advantages: Install packages on demand, no extra packages are installed at development time (Lint-related packages are development dependencies in business projects, so they only affect development time)
  • Production depend on: For business projectsWill downloadThese packages
    • Pros: Installation@jd/eslint-config-sellingAfter that, there is no need to pay attention to the front dependency packages
    • Cons: Downloads during development@jd/eslint-config-sellingFor example, if you use React, you install iteslint-plugin-vue

3. Provide simple command lines

This is a simple, interactive command that supports one-click initialization or upgrade of three specifications

Will not, guide the way in the advanced front-end essential: how to design and implement a scaffold

There is no project template scaffold in the group at present, if there is, the part of specification needs to be incorporated

Six, the most important point

What is a good specification? Basically, every team has different norms, which all team members agree with and are willing to abide by

Therefore, after confirming the technical plan, we will divide the specifications involved in the group to make the following figure, for example, several people will make styleLint and several people will make Vue…

thenLa will review, we all agreed to finalize the specificationFinally, open sourceMaintenance upgradeIn the process of use, if the specification is not appropriate, submit an issue, and we will discuss and determine whether the specification needs to be changed

Written in the end

The above is our team’s experience in the implementation of front-end specifications ~

If you’re interested, check out the Github repository