【 Front-end Engineering 】 Series of links:

  • 01 Set sail – development environment
  • 02 White Flawless – Package manager
  • Sweep the Eight Wasters -Webpack Basics
  • 04 Swept the Eight Wasteland -Webpack advanced
  • The future is here. -Babel
  • 06 Rules -ESLint

Sample code repository:Github.com/BWrong/dev-…

Declaration: If an error occurs following the code in this article, check whether the dependent version is consistent with the sample code repository.

In addition to the tools we introduced earlier, there are many useful tools, but they are too simple to cover in a separate article, so here they are.

MOCK services

Sometimes, in order to catch up with the schedule, both the front end and the back end need to be developed at the same time. Before the interface comes out, the front end needs to conduct data Mock, and then conduct joint adjustment after the interface comes out.

There are several general ways to Mock data:

  • Use online mock services such as Easy-Mock, Yapi, and Apizza.
  • Provide local services based on JSON-server.
  • Request interception to create a local mock service based on MockJs.

I usually use the third type of request interception in my projects, and I’ll briefly share this with you. Use @bwrong/mock to mock data using the before hook of webpack-dev-server.

The following functions are realized:

  • Mock file updates are automatically reloaded
  • Support for receiving request parameters and processing returned data dynamically
  • Delayed response: You can set the delayed response time for debugging loading scenarios
  • Custom headers: Headers can be set globally or for a mock interface
  • You can use the MockJS syntax
npm i -D @bwrong/mock
Copy the code
// webpack.config.js
const mockServer = require('@bwrong/mock');

module.exports = {
    // ...
    devServer: {
        before(app) {
          mockServer(app, resolve('./mock/'), {
            pattern: '**/[^_]*.js'.delay: 0.prefix: '/api'.debug: true.headers: {},
            watchOptions: {}}); }}}Copy the code

In the mock directory, index.js is used for automatic file loading, while other files are used for mock data. Each function module can be divided into a file and managed modularized.

Tip: Mock’s files are used in webpack and need to follow the CommonJS specification.

const list = {
  code: 0.msg: ' '.'data|10': [{id: '@id'.name: '@cname'.des: '@csentence'.web: '@url'.photo: '@image'.address: '@county(true)'.email: '@email'.lastIp: '@ip'.date: '@datetime(yyyy-MM-dd hh:mm:ss)'}};const info = {
  code: 0.msg: ' '.data: {
    id: '@id'.name: '@cname'.department: 'xxx'.jibTitle: 'yyy'.org: 'zzzzz'.count: {
      sum: 00 '@ integer (0100)'.score: '@ float (0,5,0,2)'.today: '@ integer (0200)'.reservation: '@ integer (0200)'}}};module.exports = [
  {
    url: '/user'.response: list
  },
  {
    url: '/testhtml'.method: 'get'.headers: {
      'Content-Type': 'text/html'
    },
    response: Test '< HTML > < h1 > HTML < / h1 > < a href = "https://www.bwrong.com" > bwrong < / a > < / HTML >'
  },
  {
    url: '/user/info/:id'.response: (req,res) = > {
      return {
        ...info,
        id: req.params.id
      }
    }
  }
];
Copy the code

The above only provides one idea, if there is a better way, welcome to hook up.

Browserslist

Configuration for sharing the target browser and Node.js versions between different front-end tools, eliminating the hassle of configuring in each tool. Can be used to:

  • autoprefix
  • babel
  • postcss-preset-env
  • eslint-plugin-compat
  • stylelint-no-unsupported-browser-features
  • postcss-normalize
  • obsolete-webpack-plugin

Configuration mode

  • In the package. The json
"browserslist": [
    "defaults"."not IE 11"."not IE_Mob 11"."maintained node versions"
]
Copy the code
  • .browserslistrc
last 1 version
> 1%
IE 10 
Copy the code

See Browserslist for more ways to use it.

PostCSS

PostCSS is a tool that allows you to use plug-ins for style transformations. It acts as a platform through which you can add plug-ins for various transformations, such as Autoprefixer, CSsmodules, stylelint, and can be used in combination with many other tools.

// webpack.config.js
module.exports = {
  module: {
    rules: [{test: /\.css$/,
        exclude: /node_modules/,
        use: [
          {
            loader: 'style-loader'}, {loader: 'css-loader'.options: {
              importLoaders: 1,}}, {loader: 'postcss-loader'}]}}Copy the code
// postcss.config.js
module.exports = {
  plugins: [
    require('precss'),
    require('autoprefixer')]}Copy the code

For details about how to use it, please refer to the official documents and official website.

Git

I believe that everyone is familiar with Git, and there are many online tutorials, SO I won’t introduce them here. However, in the process of using it, I found two issues worth mentioning again.

  • Branch management: Many people have a single master branch where everything operates, which can be inconvenient on larger teams or multiple environments. In order to have a branch management strategy, you can read Ruan Yifeng’s article Git branch management strategy.
  • Commit info: I once worked with a colleague who made all git commits’ changes’, and I’m sure I can’t get away with working overtime when it comes to code backtracking. Friendly submission information not only provides a clear view of the development record, but can also be used to generate update logs. There are a lot of solutions to Commit specifications. The most common is the Angular specification. You can also read ruan’s guide to Commit Message and Change Log writing

These plans are some reference, not necessarily suitable for every team, the best is to develop a set of norms according to the team situation in line with the needs, according to local conditions can get twice the result with half the effort.

Reading material: Exploration of standardized project development

EditorConfig

EditorConfig helps maintain a consistent coding style for multiple developers working on the same project across multiple editors and ides, a team must-have.

Editorconfig file:

# EditorConfig is awesome: https://EditorConfig.org

# top-most EditorConfig file: EditorConfig file is the top-level configuration file. If true is set, the search will stop
root = true

# unix-style newlines with a newline ending every file
[*] end_of_line = lf insert_final_newline = true # Matches multiple files with brace expansion notation # Set default Charset Set utF-8 [* for all js,py files.{js,py}]
charset = utf-8

# 4 Space indentation Controls the indentation size of the py file type
[Py] indent_style = space indent_size = 4 # Tab indentation (no size specified) [Makefile] Indent_style = TAB # Indentation override for all JS under lib directory Sets the Indentation of all JS in the lib directory to [lib/**.js]
indent_style = space
indent_Size = 2 # Matches the exact files either package. The json or. Travis. Yml set exact file package. The json /. Travis /. The types of indentation yml [{package.json,.travis.yml}] indent_style = space
indent_size = 2

Copy the code

Configuration description:

Indent_style Specifies the indentation style (TAB is hard indent, space is soft indent). Indent_size Specifies the indentation width as an integer. If indent_style is TAB, This property defaults to tab_width. Tab_width uses an integer to set the number of columns the TAB indents. The default value is indent_size end_OF_line. The value is LF, CR, and CRLF. The charset value is latin1, UTF-8, UTF-8-BOM, UTF-16BE, and UTF-16LE. Do not use UTF-8-BOM TRIM_TrailING_whitespace If this parameter is set to true, any whitespace characters at the beginning of the newline will be removed. Insert_final_newline is true to end the file with a blank line. Root is the top-level configuration fileCopy the code

The scaffold

Scaffolding we are familiar with, VueCli, Vite, CreateReactApp I believe we are familiar with, their purpose is to quickly generate project templates, improve the efficiency of development. However, these templates are very basic, and when the team has a certain size or accumulation, it is necessary to customize some of their own project templates. Then you can consider developing a set of scaffolding to manage these templates, convenient management and maintenance.

There are so many articles of this kind on the Internet, their content is similar, roughly divided into two kinds:

  • Implementation based on Yeoman: a framework that acts as a development scaffolding, it already provides a lot of stuff, you can just put your own templates in, and the community has plenty of templates to use.
  • Scaffolding development: flexible, the whole bottom need to use some tools to achieve their own, specific can see my previous blog also to disk front-end scaffolding those things.

conclusion

I finally finished it. It was supposed to take a month and it dragged on to almost three months, but it worked out.

The original

In writing this series of articles, there are several factors:

  • I am more interested in efficiency tools, maybe because the technology is too poor
  • Help the team to improve the efficiency and quality of development, now it is all about cooperation, only when the team improves, they can get better growth, a rising tide lifts all boats

The problem

As I write this long article for the first time, I have many questions:

  • The content is poorly organized
  • Article scheduling needs to be optimized
  • Writing skills need to be improved
  • Procrastination is serious, full of passion in the front, stagnation in the back
  • .

The follow-up plan

There may be a few more updates to the series later if there’s time:

  • The development of specification
  • Automated testing
  • CI/CD

Their harvest is still quite big, in order to ensure the completeness and correctness of the content, will go to a lot of information, deepen the memory; And the chain of these columns of knowledge, is no longer an island, more systematic; Additional had this part content, collect clip a lot of eat gray article can be liberated.