Note: This article is based on webPack4

Write a maintainable WebPack build configuration

The significance of the build configuration being detached into an NPM package

  • generality
    • Business developers do not need to worry about build configurations
    • Unified team build script
  • maintainability
    • Build a properly configured split
    • README document, ChangeLog document, etc
  • The quality of
    • Smoke tests, unit tests, test coverage
    • Continuous integration

Build the configuration package design

  • Manage webPack configurations for different environments through multiple profiles
    • Basic configuration: webpack.base.js
    • Development environment: webpack.dev.js
    • Build environment: webpack.prod.js
    • SSR environment: webpack.ssr.js

    .

  • Pull out into an NPM package for unified management
    • Specification: Git Commit log, README, ESLint, Semver specification
    • Quality: Smoke tests, unit tests, test coverage, and CI

This is configured using the Webpack-merge combination

  • Module. Exports = merge(baseConfig, devConfig);

Functional module design and directory structure

Build scripts using the ESLint specification

// .eslintrc.js
module.exports = {
    "parser": "babel-eslint",
    "extends": "airbnb-base",
    "env": {
        "browser": true,
        "node": true
    }
};
Copy the code

Smoke test execution

  • Whether the build was successful
  • Whether the build directory has content output each time the build completes
    • Whether static resource files such as JS and CSS exist
    • Whether there is an HTML file

Determine if the build was successful

  • Run the build in the sample project and see if any errors are reported

Determine whether the basic functions are normal

  • Write mocha test cases
    • Whether static resource files such as JS and CSS exist
    • Whether there is an HTML file

Unit testing and test coverage

  • Technical selection: Mocha + Chai
  • Test code: describe, IT, except
  • Test command: mocha add.test.js

Unit test access

    1. Install mocha + chai NPM I mocha chai -d
    1. Create the test directory and add the xxx.test.js test file
    1. Json: {“test”: “node_modules/mocha/bin/_mocha “}
    1. Run the NPM run test command

The role of continuous integration

  • Advantages:
    • Quick Error detection
    • Prevents branches from deviating significantly from the trunk

The core measure is that code must pass automated tests before it can be integrated into the trunk. As long as one test case fails, the integration is not possible.

Access to the Travis CI

    1. Travis-ci.org/ log in using your GitHub account
    1. In travis-ci.org/account/rep… Start for a project
    1. Add.travis. Yml to the project root directory

Travis. Yml File content

  • Install Indicates the installation project dependency
  • Script runs the test cases

Published to the NPM

  • Adduser: NPM adduser
  • Upgraded version
    • Patch version: NPM version patch
    • Minor version: NPM Version Minor
    • Upgrade version: NPM Version Major
  • Publish version: NPM Publish

Git specification and Changelog generation

  • Good Git Commit specification advantages:
    • Speed up Code Review process
    • Generate a Changelog based on the metadata of Git Commit
    • The subsequent maintainer can know why the Feature is modified

Submission Format Requirements

Add precommit hooks for local development

  • Install the husky
  • npm install husky –save-dev
  • Check the message using the commitMSG hook
"scripts": { "commitmsg": "validate-commit-msg", "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0" }, "devDependencies": { "validate-commit-msg": "^ 2.11.1", "but - changelog - cli" : "^ 1.2.0", "husky" : "^ 0.13.1"}Copy the code

Open source project version information case

  • A software version usually consists of three digits, such as X.Y.Z
  • The version is strictly incrementing, in this case: 16.2.0 -> 16.3.0 -> 16.3.1
  • Prior releases, such as alpha, RC, etc. can be released when a major release is released
  • In modified versions such as alpha and RC, the keyword can be followed by count and meta information

Advantages of complying with the Semver specification

  • Advantage:
    • Avoid circular dependencies
    • Dependency conflict reduction

Semantic Versioning is a canonical format

  • Major version number: When you make an incompatible API change,
  • Sub-release number: When you make backwards compatible functionality additions,
  • Revision number: When you make a backwards compatibility issue fix.

Prior version number

The prior release number can be used as the version before the official release by following the revision number with a link (-) followed by a series of dots (.). A split identifier. The identifier can consist of English, digits, and hyphens ([0-9a-za-Z -]).

  • Alpha: An internal beta version that is usually not released to the outside world and is buggy. Usually only used by testers.
  • Beta: This is the beta version, and new features will be added all the time. After the Alpha release
  • Rc: Release Candidate) on the system platform. – there will be no new functionality in RC, the focus will be on debugging.

Code repository: github.com/glihui/guo-…

Finally:

If you have a dream, you must come to the big city, here can help you achieve your dream

Some dreams need the power of cities to achieve

Links to other articles in this series

  • Webpack covers everything from the light to the deep, so that your resume is really “familiar” (Series 1)
  • Webpack covers everything from the light to the deep, so that your resume is really “familiar” (Series 2)
  • Webpack covers everything from the shallow to the deep, so that your resume really says “familiar” (Series 3)
  • Webpack covers everything from the shallow to the deep, so that your resume is really “familiar” (Series 4)
  • Webpack covers everything from the light to the deep, making your resume truly “familiar” (Series 5)