2 |
3 | [English](./README.md) | [中文](./README.zh.md)
4 |
5 | [Source code analysis](#source_code_analysis)
6 |
7 | ## Introduction
8 |
9 | - ✨ easy to develop: one line command to start react + less project
10 | - ✨ easy to pack business code: one line of command to package react business projects, using webpack5, no need to pay attention to webpack configuration and optimization, we have done it for you
11 | - ✨ easy to package react component library: one line of command to package react component library, the packaging method is the same as ant design (package component library should be loaded on demand, which is different from the configuration of business code packaging)
12 |
13 | ## Project Description
14 |
15 | - Use @mx-deisgn/cli to quickly start the development environment and package the project (the case is under the example folder)
16 |
17 | ## Install
18 |
19 | use `npm`
20 |
21 | ```node
22 | npm install @mx-design/cli --save-dev
23 | ```
24 |
25 | or use `yarn`
26 |
27 | ```node
28 | yarn add @mx-design/cli --dev
29 | ```
30 |
31 | ## Usage
32 |
33 | ```node
34 | mx buildLib [options] package and compile react component library
35 | mx dev [options] run the development environment
36 | mx buildSite [options] package and compile web projects
37 | mx --help view help information
38 | mx --version view version information
39 | ```
40 |
41 | ## Detailed commands are as follows
42 |
43 | Add in devDependencies of package.json
44 |
45 | ```javascript
46 | "devDependencies": {
47 | + "@mx-design/cli": "xxx"
48 | }
49 | ```
50 |
51 | Development environment configuration
52 |
53 | ```javascript
54 | "scripts": {
55 | "start": "mx dev",
56 | },
57 | ```
58 |
59 | In order to realize the custom configuration of the dev environment, we will also read your mx.config.js file in the root directory, as follows:
60 |
61 | ```javascript
62 | //mx.config.js
63 | const path = require('path');
64 |
65 | module.exports = {
66 | // Custom entry file, required
67 | entries: {
68 | index: {
69 | entry: ['./src/index.js'],
70 | template: './public/index.html',
71 | favicon: './favicon.ico',
72 | },
73 | // Alias configuration, can be omitted
74 | resolve: {
75 | alias: {
76 | '@': path. join(process. cwd(), '/'),
77 | },
78 | },
79 | // Add a custom Babel plugin
80 | setBabelOptions: (options) => {
81 | options.plugins.push([
82 | 'prismjs',
83 | {
84 | languages: ['javascript', 'typescript', 'jsx', 'tsx', 'css', 'scss', 'markup', 'bash'],
85 | theme: 'default',
86 | css: true,
87 | },
88 | ]);
89 | },
90 | // add custom loader
91 | setRules: (rules) => {
92 | rules. push({
93 | test: /\.md$/,
94 | use: ['raw-loader'],
95 | });
96 | },
97 | };
98 |
99 | ```
100 |
101 | Well, this is how to configure the development environment. Isn’t it very simple? Currently, we use webpack5 to start the development environment.No need to configure webpack yourself.
102 |
103 | Build business code is simpler
104 |
105 | ```javascript
106 | "scripts": {
107 | "start": "mx buildSite",
108 | }
109 | ```
110 |
111 | We will also read the mx.config.js file configuration in your root directory, and of course some command line options for traversal, such as
112 |
113 | ```javascript
114 | "scripts": {
115 | "start": "mx buildSite --analyzer", // enable package analyzer
116 | }
117 |
118 | "scripts": {
119 | "start": "mx buildSite --out-dir lib", // The packaged address directory defaults to dist, here it is changed to lib
120 | }
121 | ```
122 |
123 | The command line of the packaged component library is as follows (the following are the recommended configurations, just enter npm/yarn run build on the command line):
124 |
125 | ```javascript
126 | "scripts": {
127 | "build:types": "rimraf types && tsc --outDir types -d --emitDeclarationOnly",
128 | "build:es": "rimraf esm && mx buildLib --mode esm --entry-dir ./components --less-2-css --copy-less",
129 | "build:cjs": "rimraf lib && mx buildLib --mode cjs --entry-dir ./components --less-2-css --copy-less",
130 | "build:umd": "rimraf dist && mx buildLib --mode umd --entry ./components/index",
131 | "build": "yarn build:types && yarn build:cjs && yarn build:es && yarn build:umd",
132 | }
133 | ```
134 |
135 | The above command is explained as follows:
136 |
137 | - `--mode cjs`
138 | - pack commonjs
139 | - `--mode esm`
140 | - pack es module
141 | - `--mode umd`
142 | - pack umd
143 | - `--less-2-css`
144 | - convert less to css
145 | - `--entry-dir`
146 | - mode is valid for esm and cjs
147 | - The entry directory when passing in packaging, the default is src
148 | - `--entry`
149 | - umd mode takes effect
150 | - umd entry file default is src/index
151 | - `--copy-less`
152 | - copy the less file to
153 | - `-out-dir-umd`
154 | - It takes effect when the mode is umd mode
155 | - output directory in umd format, the default is `./dist`
156 | - `--out-dir-esm`
157 | - Output directory in esm format, the default is `./esm`
158 | - `--out-dir-cjs`
159 | - Output directory in cjs format, default `./lib'`
160 | - `--analyzerUmd`
161 | - Whether to enable analyzers for webpack packaging
162 |
163 | All the detailed parameters of the above command can be viewed as follows:
164 |
165 | ```javascript
166 | "scripts": {
167 | "buildLibHelp": "mx help buildLib", // View command line parameters of all packaged component libraries
168 | "buildSiteHelp": "mx help buildSite", // View all command line parameters of
169 | "devHelp": "mx help dev", // View all dev environment configuration parameters
170 | }
171 | ```
172 |
173 | ## case
174 |
175 | There is a case under the example folder, after installing the dependencies of the package, you can start it with `npm run dev`
176 |
177 | ## Source_code_analysis
178 |
179 | ### use commander to read command line parameters
180 |
181 | How about creating your own mx command?
182 |
183 | In the bin field of package.json, add
184 |
185 | ```json
186 | "bin": {
187 | "mx": "./bin/index.js"
188 | },
189 | ```
190 |
191 | In this way, when someone downloads your npm package, and use the mx command, it will execute index.js in the bin directory of your npm package.
192 |
193 | Let's see what index.js looks like
194 |
195 | ```bash
196 | #!/usr/bin/env node
197 |
198 | require('../lib/index');
199 | ```
200 |
201 | It is very simple to execute the index.ts file under the lib
202 |
203 | The lib directory is our final generated component library (for example, we need to compile ts into js, babel compile syntax, etc.), and the index.js inside is the entry file. Let's look at the index.ts.
204 |
205 | Before explaining the index.ts file, I need to introduce the simple usage of the commander library
206 |
207 | ```javascript
208 | // index.js
209 | const program = require('commander');
210 | program.version('1.0.0').parse(process.argv);
211 | ```
212 |
213 | Executing the above code `node index.js -V` or `node index.js --version` will get the version number 1.0.0
214 | program.version('1.0.0') means to register the command, and parse means to parse the parameters of the command line, here pass in process.argv, which means to parse the parameters in process.argv, so we enter `node index.js - -version`, in fact, is to pass the parameter version to the commander
215 |
216 | We only need to get the version field in package.json, so we will get the version number of the cli tool
217 |
218 | index.ts in the src directory
219 |
220 | ```typescript
221 | import commander from 'commander';
222 |
223 | import { buildLib } from './buildLib/index';
224 | import { buildSite } from './buildSite/index';
225 | import { runDev } from './dev/index';
226 | import { version } from '../package.json';
227 |
228 | commander.version(version, '-v, --version');
229 |
230 | buildLib(commander);
231 | buildSite(commander);
232 | runDev(commander);
233 |
234 | commander.parse(process.argv);
235 |
236 | if (!commander.args[0]) {
237 | commander.help();
238 | }
239 | ```
240 |
241 | ## Development environment configuration
242 |
243 | Let's first take a look at the function `runDev(commander)` executed when mx dev is executed. What is the running process of this function? The runDev function is as follows
244 |
245 | ```javascript
246 | // When you execute mx dev, development code will execute
247 | import development from './development';
248 | import { DEV } from '../constants';
249 |
250 | export const runDev = (commander) => {
251 | // Commander registers the command with the parameter 'dev'
252 | commander
253 | .command(DEV)
254 | .description('Run development environment')
255 | .option('-h, --host ', 'site host address', 'localhost')
256 | // The default port number is 3000
257 | .option('-p, --port ', 'site port number', '3000')
258 | // The file that the command will eventually run on
259 | .action(development);
260 | };
261 | ```
262 |
263 | This development has 3 key issues:
264 |
265 | - How to write a compose function to improve your code quality, students who do not know the compose function, please read this article [Ultimate Compose Function Encapsulation Solution](https://juejin.cn/post/6989815456416661534), or you can just look at me The following code will understand
266 |
267 | - How to start WebpackDevServer
268 | - When starting, we will start the default port 3000, so if port 3000 is already occupied, we will advance until port 3000 is occupied, and find an unoccupied port for webpackDevServer to start?
269 |
270 | ### The first question: How to write an elegant function iterator to merge configurations
271 |
272 | Our compose code here is as follows:
273 |
274 | ```javascript
275 | // synchronous function chain
276 | export const syncChainFns = (...fns) => {
277 | const [firstFn, ...otherFns] = fns;
278 | return (...args) => {
279 | if (!otherFns) return firstFn(...args);
280 | return otherFns.reduce((ret, task) => task(ret), firstFn(...args));
281 | };
282 | };
283 | ```
284 |
285 | Let's write a simple case call:
286 |
287 | ```javascript
288 | function add(a, b) {
289 | return a + b;
290 | }
291 | function addVersion(sum) {
292 | return `version: ${sum}.0.0`;
293 | }
294 |
295 | syncChainFns(add, addVersion)(1, 2); // 'version: 3'
296 | ```
297 |
298 | That is to say, our function chain is like a factory processing goods. After No. 1 person processes it, he will continue to process it for the next person, and finally get the result, which can be realized by analogy with redux's compose function. This is the idea of functional programming.
299 |
300 | We will use this function to process webpack configuration later, because webpack configuration can be divided into 4 functions for processing
301 |
302 | - First there is an initial webpack dev configuration
303 | - Then there are user-defined configurations, such as creating a mx.config.js file yourself as a configuration file
304 | - Whether it is a ts environment, the name must add ForkTsCheckerWebpackPlugin to the webpack plugin to speed up the compilation of ts
305 | - Finally, it is handed over to the webpack function for compilation, so that the value that is finally handed over to webpackDevServer to start is generated
306 |
307 | ### The second question: How to start WebpackDevServer
308 |
309 | note that this is the starting method of webpack5, which is different from the parameter position of the previous 4
310 |
311 | ```javascript
312 | const serverConfig = {
313 | publicPath: '/',
314 | compress: true,
315 | noInfo: true,
316 | hot: true,
317 | };
318 | const devServer = new WebpackDevServer(compiler, serverConfig);
319 | ```
320 |
321 | ### The third question: What should I do if the port number used to start dev is occupied?
322 |
323 | We use a library called detect to detect whether the port is occupied. If the library finds that the port is occupied, it will return an unoccupied port number
324 |
325 | ```javascript
326 | const resPort = await detect(port, host);
327 | ```
328 |
329 | Well, these three problems have been solved. Let’s take a brief look at the development file.
330 |
331 | ```javascript
332 | import webpack from 'webpack';
333 | import WebpackDevServer from 'webpack-dev-server';
334 | import getWebpackConfig from '../config/webpackConfig';
335 | import { isAddForkTsPlugin, syncChainFns, getProjectConfig } from '../utils';
336 | import { DEV } from '../constants';
337 | import { IDevelopmentConfig } from '../interface';
338 | import detect from 'detect-port-alt';
339 |
340 | const isInteractive = process.stdout.isTTY;
341 |
342 | async function choosePort(port, host) {
343 | const resPort = await detect(port, host);
344 | if (resPort === Number(port)) {
345 | return resPort;
346 | }
347 | const message = `Something is already running on port ${port}.`;
348 |
349 | if (isInteractive) {
350 | console.log(message);
351 | return resPort;
352 | }
353 | console.log(message);
354 | return null;
355 | }
356 |
357 | export default ({ host, port }: IDevelopmentConfig) => {
358 | const compiler = syncChainFns(
359 | getWebpackConfig,
360 | getProjectConfig,
361 | isAddForkTsPlugin,
362 | webpack
363 | )(DEV);
364 |
365 | const serverConfig = {
366 | publicPath: '/',
367 | compress: true,
368 | noInfo: true,
369 | hot: true,
370 | };
371 | const runDevServer = async (port) => {
372 | const devServer = new WebpackDevServer(compiler, serverConfig);
373 | const resPort = await choosePort(port, host);
374 | if (resPort !== null) {
375 | devServer.listen(resPort, host, (err) => {
376 | if (err) {
377 | return console.error(err.message);
378 | }
379 | console.warn(`http://${host}:${resPort}\n`);
380 | });
381 | }
382 | };
383 | runDevServer(port);
384 | };
385 | ```
386 |
387 | ### Packaging business code script analysis
388 |
389 | packaging the business code and packaging the component library, do you know the difference?
390 |
391 | For the business component library, at present, using webpack is one of the most suitable choices, because the code for our business launch needs stability. The ecology and ecological stability of webpack are not available in many packaging tools, and no development is required. The efficiency of the environment (webpack5 is much faster than 4), for example, some people choose to use vite for the development environment.
392 |
393 | Business codes are generally packaged in umd format.
394 |
395 | The component library code, such as ant design, element ui, these libraries not only need the umd format, but also the esm module, which exports the import syntax, which cannot be done by webpack. The reason why it can't be done is because webpack has its own set of require rules, and the import you use will eventually be translated by webpack's set of loading module syntax.
396 |
397 | So you can use roll up for the esm module, but after careful research, I found that multi-entry packaging rollup is not supported, and we need to work hard on css packaging. Later, packaging css is very, very particular Yes, rollup is not enough, so we directly use gulp to package css and js separately.
398 |
399 | It is because of the high customization requirements that we have to use glup to customize the packaging process.
400 |
401 | Let's take a look at the entry of the simpler packaged business code script
402 |
403 | ```javascript
404 | import build from './buildSite';
405 | import { BUILD_SITE } from '../constants';
406 |
407 | export const buildSite = (commander) => {
408 | // package business components
409 | // This command actually executes the buildSite file
410 | commander
411 | .command(BUILD_SITE)
412 | .description('Package business code')
413 | .option('-d, --out-dir ', 'Output directory', 'dist')
414 | .option('-a, --analyzer', 'whether to enable the analyzer')
415 | .action(build);
416 | };
417 | ```
418 |
419 | Next, let's look at the build file. The following mainly explains the code of the getWebpackConfig file and the getProjectConfig file
420 |
421 | ```javascript
422 | import webpack from 'webpack';
423 | // webpack code packaging analysis plugin
424 | import { BundleAnalyzerPlugin } from 'webpack-bundle-analyzer';
425 | // Get webpack basic configuration
426 | import getWebpackConfig from '../config/webpackConfig';
427 | import { getProjectPath, getProjectConfig, syncChainFns } from '../utils';
428 | // interface configuration
429 | import { IDeployConfig } from '../interface';
430 | // This constant is the string "buildSite"
431 | import { BUILD_SITE } from '../constants';
432 | export default ({ outDir, analyzer }: IDeployConfig) => {
433 | // This syncChainFns function has been introduced above, it is a combiner of function combinations
434 | const config = syncChainFns(
435 | // This function will be mentioned later, which is to obtain the configuration files of webpack in different environments
436 | getWebpackConfig,
437 | // This function will be mentioned later to obtain the user-defined webpck configuration file
438 | getProjectConfig,
439 | // Determine whether you need to add a plug-in to speed up the parsing of ts
440 | isAddForkTsPlugin
441 | )(BUILD_SITE);
442 | config.output.path = getProjectPath(outDir);
443 |
444 | // Whether to enable the code package size analysis plugin
445 | if (analyzer) {
446 | config.plugins.push(
447 | new BundleAnalyzerPlugin({
448 | analyzerMode: 'static',
449 | generateStatsFile: true,
450 | })
451 | );
452 | }
453 |
454 | webpack(config).run((err) => {
455 | if (err) {
456 | logger.error('webpackError: ', JSON.stringify(err));
457 | }
458 | });
459 | };
460 | ```
461 |
462 | The following is the getWebpackConfig function, which is relatively simple. It is to call different functions according to different parameters on the command line, such as mx dev, to call the getDevConfig function to obtain the configuration of webpack in the dev environment
463 |
464 | ```javascript
465 | const getWebpackConfig = (type?: IWebpackConfigType): Configuration => {
466 | switch (type) {
467 | case DEV:
468 | return getDevConfig();
469 |
470 | case BUILD_SITE:
471 | return getBuildConfig();
472 |
473 | case BUILD_LIB:
474 | return getBuildConfig();
475 |
476 | default:
477 | return getDevConfig();
478 | }
479 | };
480 | ```
481 |
482 | getProjectConfig is mainly a function for user-defined configuration. We mainly analyze how to get user-defined configuration.
483 |
484 | ```javascript
485 | export const getCustomConfig = (
486 | configFileName = 'mx.config.js'
487 | ): Partial => {
488 | const configPath = path.join(process.cwd(), configFileName);
489 | if (fs.existsSync(configPath)) {
490 | // eslint-disable-next-line import/no-dynamic-require
491 | return require(configPath);
492 | }
493 | return {};
494 | };
495 | ```
496 |
497 | As you can see, it is to read mx.config.js under the project. You can configure your own webpack loaders, webpack plugins, etc
498 |
499 | ```javascript
500 | const path = require('path');
501 |
502 | module.exports = {
503 | entries: {
504 | index: {
505 | entry: ['./web/index.js'],
506 | template: './web/index.html',
507 | favicon: './favicon.ico',
508 | },
509 | },
510 | resolve: {
511 | alias: {
512 | '@': path.join(process.cwd(), '/'),
513 | },
514 | },
515 | setBabelOptions: (options) => {
516 | options.plugins.push(['import', { libraryName: 'antd', style: 'css' }]);
517 | },
518 | setRules: (rules) => {
519 | rules.push({
520 | test: /\.md$/,
521 | use: ['raw-loader'],
522 | });
523 | },
524 | };
525 | ```
526 |
527 | ### the configuration of the component library
528 |
529 | The code for packaging the component library is much more complicated than before!
530 |
531 | ```javascript
532 | import build from './build';
533 | import { BUILD_LIB } from '../constants';
534 |
535 | export const buildLib = (commander) => {
536 | // When you enter mx buildLib, this command is executed
537 | // This command actually executes the build file
538 | // We will package two packages of es and commonjs specifications
539 | commander
540 | .command(BUILD_LIB)
541 | .description('package and compile warehouse')
542 | .option(
543 | '-a, --analyzerUmd',
544 | 'Whether to enable the webpack package analyzer'
545 | )
546 | .option('-e, --entry ', 'umd package path entry file', './src/index')
547 | .option(
548 | '--output-name ',
549 | 'The name exposed to the outside world after packaging Umd format'
550 | )
551 | .option(
552 | '--entry-dir ',
553 | 'cjs and esm packaging path entry directory',
554 | './src'
555 | )
556 | .option('--out-dir-umd ', 'Output directory in umd format', './dist')
557 | .option('--out-dir-esm ', 'Output directory in esm format', './esm')
558 | .option('--out-dir-cjs ', 'output directory in cjs format', './lib')
559 | .option('--copy-less', 'Copy files that do not participate in compilation')
560 | .option('--less-2-css', 'Whether to compile component styles')
561 | .option(
562 | '-m, --mode ',
563 | 'package mode currently supports umd and esm'
564 | )
565 | .action(build);
566 | };
567 | ```
568 |
569 | Let's look at the build file, which is the file that is executed after you enter mx buildLib. Let's first look at the packaging of umd. This is simple.
570 |
571 | ```javascript
572 | import webpack from 'webpack';
573 | import webpackMerge from 'webpack-merge';
574 | // gulp task, will be discussed later
575 | import { copyLess, less2css, buildCjs, buildEsm } from '../config/gulpConfig';
576 | import getWebpackConfig from '../config/webpackConfig';
577 | // Tool function, we will talk about it later
578 | import { getProjectPath, logger, run, compose } from '../utils';
579 | // Code package size analysis plugin
580 | import { BundleAnalyzerPlugin } from 'webpack-bundle-analyzer';
581 | // environment constant
582 | import {
583 | BUILD_LIB,
584 | CJS,
585 | ESM,
586 | UMD,
587 | COPY_LESS,
588 | LESS_2_LESS,
589 | CLEAN_DIR,
590 | } from '../constants';
591 |
592 | // The name attribute of package.json is used as the package name, of course, it can also be customized
593 | const { name } = require(getProjectPath('package.json'));
594 | // Check whether the name has a slash, which will affect the packaged result
595 | const checkName = (outputName, name) => {
596 | if (!outputName && name?.includes('/')) {
597 | logger.warn(
598 | 'The package name of package.json contains slashes, and webpack will create folders with slashes when packaging, so please pay attention to whether the file name after packaging meets your requirements'
599 | );
600 | }
601 | };
602 | /**
603 | * build for umd
604 | * @param analyzer Whether to enable the analysis package plugin
605 | * @param outDirUmd output directory
606 | * @param entry packaged entry file
607 | * @param outputName packaged name
608 | */
609 | const buildUmd = async ({ analyzerUmd, outDirUmd, entry, outputName }) => {
610 | const customizePlugins = [];
611 | const realName = outputName || name;
612 | checkName(outputName, name);
613 | const umdTask = (type) => {
614 | return new Promise((resolve, reject) => {
615 | const config = webpackMerge(getWebpackConfig(type), {
616 | entry: {
617 | [realName]: getProjectPath(entry),
618 | },
619 | // The main purpose here is to set the libraryTarget to set the packaging format to umd
620 | // library is configured package name
621 | output: {
622 | path: getProjectPath(outDirUmd),
623 | library: realName,
624 | libraryTarget: 'umd',
625 | libraryExport: 'default',
626 | },
627 | plugins: customizePlugins,
628 | });
629 |
630 | if (analyzerUmd) {
631 | config.plugins.push(
632 | new BundleAnalyzerPlugin({
633 | analyzerMode: 'static',
634 | generateStatsFile: true,
635 | })
636 | );
637 | }
638 | return webpack(config).run((err, stats) => {
639 | if (stats.compilation.errors?.length) {
640 | console.log('webpackError: ', stats.compilation.errors);
641 | }
642 | if (err) {
643 | logger.error('webpackError: ', JSON.stringify(err));
644 | reject(err);
645 | } else {
646 | resolve(stats);
647 | }
648 | });
649 | });
650 | };
651 | logger.info('building umd');
652 | await umdTask(BUILD_LIB);
653 | logger.success('umd computed');
654 | };
655 | ```
656 |
657 | Next, let’s talk about the most complicated gulp configuration, first look at the entry file:
658 |
659 | - Before we write a compose function of a framework similar to koa, this function is a function executor that calls each asynchronous function in order, for example, there are asynchronous function 1, asynchronous function 2, asynchronous function 3, I need to follow the order Call 1, 2, 3, and these 1, 2, 3 are decoupled, joined in the form of middleware, and share some data
660 |
661 | Let's look at the function first:
662 |
663 | ```javascript
664 | export function compose(middleware, initOptions) {
665 | const otherOptions = initOptions || {};
666 | function dispatch(index) {
667 | if (index == middleware.length) return;
668 | const currMiddleware = middleware[index];
669 | return currMiddleware(() => dispatch(++index), otherOptions);
670 | }
671 | dispatch(0);
672 | }
673 | ```
674 |
675 | This function means:
676 |
677 | - Get the middleware functions in array order
678 | - Then when the function is called, the first parameter is passed to the next called function, and pass in the global shared data props: otherOptions.
679 |
680 | The following is the file that uses the compose function to execute each function, that is, the file actually executed by mx buildLib. There are too many files, so I will use a build esm to explain
681 |
682 | ```javascript
683 | import webpack from 'webpack';
684 | import webpackMerge from 'webpack-merge';
685 | // gulp task
686 | import { copyLess, less2css, buildCjs, buildEsm } from '../config/gulpConfig';
687 | import getWebpackConfig from '../config/webpackConfig';
688 | // Tool function
689 | import { getProjectPath, logger, run, compose } from '../utils';
690 | import { BundleAnalyzerPlugin } from 'webpack-bundle-analyzer';
691 | // environment constant
692 | import {
693 | BUILD_LIB,
694 | CJS,
695 | ESM,
696 | UMD,
697 | COPY_LESS,
698 | LESS_2_LESS,
699 | CLEAN_DIR,
700 | } from '../constants';
701 |
702 | const buildLib = async ({
703 | analyzerUmd,
704 | mode,
705 | entry,
706 | outDirEsm,
707 | outDirCjs,
708 | outDirUmd,
709 | copyLess,
710 | entryDir,
711 | less2Css,
712 | cleanDir,
713 | outputName,
714 | }) => {
715 | // Register middleware, and then use the compose function to combine
716 | const buildProcess = [bulidLibFns[CLEAN_DIR]];
717 | // Whether to pack the umd format, if yes, add the umd packaging function we talked about before
718 | if (mode === UMD) {
719 | buildProcess.push(bulidLibFns[UMD]);
720 | }
721 | // Whether to pack the esm format, if yes, add the corresponding packing function,
722 | if (mode === ESM) {
723 | buildProcess.push(bulidLibFns[ESM]);
724 | }
725 | // Omit some codes, just to add various processing functions, such as whether to add middleware that compiles less to css
726 | compose(buildProcess, {
727 | analyzerUmd,
728 | mode,
729 | entry,
730 | outDirEsm,
731 | outDirCjs,
732 | outDirUmd,
733 | copyLess,
734 | entryDir,
735 | less2Css,
736 | cleanDir,
737 | outputName,
738 | });
739 | };
740 | ```
741 |
742 | Let's take a look at the gulp configuration file buildesm, which mainly executes the compileScripts function. Let's look at this function next.
743 |
744 | ```javascript
745 | const buildEsm = ({ mode, outDirEsm, entryDir }) => {
746 | const newEntryDir = getNewEntryDir(entryDir);
747 | /**
748 | * compile esm
749 | */
750 | gulp.task('compileESM', () => {
751 | return compileScripts(mode, outDirEsm, newEntryDir);
752 | });
753 |
754 | return new Promise((res) => {
755 | return gulp.series('compileESM', () => {
756 | res(true);
757 | })();
758 | });
759 | };
760 | ```
761 |
762 | ```javascript
763 | /**
764 | * Compile the script file
765 | * @param {string} babelEnv babel environment variable
766 | * @param {string} destDir destination directory
767 | * @param {string} newEntryDir entry directory
768 | */
769 | function compileScripts(mode, destDir, newEntryDir) {
770 | const { scripts } = paths;
771 | return gulp
772 | .src(scripts(newEntryDir)) // find the entry file
773 | .pipe(babel(mode === ESM ? babelEsConfig : babelCjsConfig)) // use gulp-babel processing
774 | .pipe(
775 | // use gulp to process css
776 | through2.obj(function z(file, encoding, next) {
777 | this.push(file.clone());
778 | // find target
779 | if (file.path.match(/(\/|\\)style(\/|\\)index\.js/)) {
780 | const content = file.contents.toString(encoding);
781 | file.contents = Buffer.from(cssInjection(content)); // process file content
782 | file.path = file.path.replace(/index\.js/, 'css.js'); // file rename
783 | this.push(file); // add this file
784 | next();
785 | } else {
786 | next();
787 | }
788 | })
789 | )
790 | .pipe(gulp.dest(destDir));
791 | }
792 | ```
793 |
794 | ## webpack configuration details
795 |
796 | ### output
797 |
798 | ```
799 | output: {
800 | filename: 'js/[name].js',
801 | chunkFilename: 'js/[name].[chunkhash:8].js',
802 | assetModuleFilename: 'asset/[name].[contenthash:8].[ext]',
803 | }
804 | ```
805 |
806 | - filename specifies the name of the main code file generated after packaging. [name] here means to use the name of the entry file (entry) as the file name and output it to the js folder.
807 |
808 | - chunkFilename specifies the file name of the non-entry file generated by webpack packaging, such as the code block generated by code splitting. The placeholder [chunkhash:8] is used here to ensure the uniqueness of the file name and the caching effect.
809 |
810 | - assetModuleFilename is used to specify the output path and name of resource files (images, fonts, etc.) processed by webpack when packaging. The placeholder [contenthash:8] is used to ensure the caching effect of resource files. [ext] is used to preserve the file extension.
811 |
812 | The above configuration will package all JS files into the js directory, and package other types of resource files into the asset directory.
813 |
814 | ### optimization
815 |
816 | ```javascript
817 | optimization: {
818 | runtimeChunk: true,
819 | splitChunks: {
820 | minChunks: 2,
821 | chunks: 'all',
822 | cacheGroups: {
823 | reactBase: {
824 | name: 'reactBase',
825 | chunks: 'all',
826 | test: /[\\/]node_modules[\\/](react|react-dom|@hot-loader|react-router|react-redux|react-router-dom)[\\/]/,
827 | },
828 | 'async-commons': {
829 | // Asynchronously load public packages, components, etc.
830 | name: 'async-commons',
831 | chunks: 'async',
832 | test: /[\\/]node_modules[\\/]/,
833 | minChunks: 2,
834 | priority: 1,
835 | },
836 | },
837 | },
838 | },
839 | ```
840 |
841 | - runtimeChunk: true The configuration item is used to package the Webpack runtime code into a separate file, so that each module does not contain duplicate runtime code. This improves cache utilization and speeds up builds.
842 |
843 | What is runtime code? Webpack runtime code refers to some code snippets generated by Webpack when packaging to handle module loading and resolution, dependency management, code splitting, and some other internal functions of Webpack. For example:
844 |
845 | ```javascript
846 | // Webpack runtime code snippet 1: module loading
847 | (function(modules) {
848 | // module cache object
849 | var installedModules = {};
850 |
851 | // load module function
852 | function __webpack_require__(moduleId) {
853 | // check if the module is cached
854 | if(installedModules[moduleId]) {
855 | return installedModules[moduleId].exports;
856 | }
857 |
858 | // Create a new module object and cache it
859 | var module = installedModules[moduleId] = {
860 | i: moduleId,
861 | l: false,
862 | exports: {}
863 | };
864 |
865 | // load the module
866 | modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
867 |
868 | // mark module loaded
869 | module.l = true;
870 |
871 | // Return the exported object of the module
872 | return module. exports;
873 | }
874 | ...
875 | ```
876 |
877 | - The splitChunks configuration item is used to split the code into smaller chunks to make better use of the browser's caching mechanism. Specifically, the following are configured here:
878 |
879 | - minChunks: 2 indicates the minimum number of code reuse, that is, when a module is referenced by at least two Chunks, it will be split into a separate Chunk.
880 |
881 | - chunks: 'all' means to optimize all types of Chunk, including synchronous and asynchronous Chunk.
882 |
883 | - cacheGroups represents a cache group, which can pack modules that meet certain conditions into a group for better splitting and caching. Two cache groups are defined here:
884 |
885 | - The reactBase cache group packs React-related modules into a Chunk named reactBase, and only includes React-related modules in the node_modules directory.
886 |
887 | - The async-commons cache group packs other common modules into an asynchronous Chunk named async-commons, which only contains modules under the node_modules directory and is referenced by at least two asynchronous Chunks. The cache group has a priority of 1 to ensure that it is split into a single chunk.
888 |
889 | ## loader
890 |
891 | As mentioned above, you can expand the loader through mx.config.js. The loader that comes with mx-design-cli itself has
892 |
893 | - babel-loader
894 | - test rule: /\.(js|jsx|ts|tsx)$/
895 | - Speed up compilation with thread-loader
896 | - css related loader
897 | - css loader
898 | - postcss-loader
899 | -less-loader
900 | - picture related loader
901 | - webpack5 built-in loader
902 | - test rules: [/\.bmp$/, /\.gif$/, /\.jpe?g$/, /\.png$/]
903 | - less than 4 \* 1024 will be compiled into date URL format
904 | - font related loader
905 | - webpack5 built-in loader
906 | - test rule: /\.(eot|ttf|woff|woff2?)$/
907 | - svg related loader
908 | - @svgr/webpack loader
909 |
910 | ## resolve
911 |
912 | ```javascript
913 | resolve: {
914 | extensions: [' ', '.ts', '.tsx', '.js', '.jsx', '.less', '.svg'],
915 | },
916 | ```
917 |
918 | The resolve option tells Webpack what file extensions to look for when resolving modules. In this example, Webpack will look for the following file extensions in order: .ts, .tsx, .js, .jsx, .less, .svg. When we refer to these files in the import statement, Webpack will use this option to resolve the module path.
919 |
920 | ## plugins
921 |
922 | ```javascript
923 | plugins: [
924 | new WebpackBar({}),
925 | new webpack. DefinePlugin({
926 | 'process.env': JSON.stringify(process.env),
927 | }),
928 | ],
929 | ```
930 |
931 | we use the WebpackBar plugin and the DefinePlugin plugin.
932 |
933 | The WebpackBar plugin can display a progress bar on the command line, allowing us to understand the progress of Webpack's construction more intuitively.
934 |
935 | The DefinePlugin plugin can define global variables at compile time. Here we define process.env as the current environment variable, so that our code can execute different logic according to different environment variables.
936 |
937 | The above is the basic webpack configuration, and the production and development environments will be handled differently, for example
938 |
939 | ### Development Environment
940 |
941 | The development environment, such as plugins that need hot updates, sourceMap content will be more detailed, etc...
942 |
943 | ### Production environment (business code packaging, not component library)
944 |
945 | Need to do a good split chunk to better use the cache to store the library under node_modules (because there are fewer changes), for example, you can use TerserPlugin to enable multi-threaded packaging, CssMinimizerPlugin to enable css compression, etc...
946 |
--------------------------------------------------------------------------------