如何自定义配置Angular CLI下的Webpack和loader处理

今天就跟大家聊聊有关如何自定义配置Angular CLI下的Webpack和loader处理，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

1 Angular 使用自定义Webpack配置方法

1.1 背景

使用Angular CLI新建工程后，一键式的配置已经能满足大部分需求，但针对个体述求，可能会希望给webpack配置一些额外的loader或者plugins。【相关教程推荐：《angular教程》】

1.2 替换Builder实现外部配置webpack

angular.json 暴露了多种Builder可以替换的接口，如果需要使用自定义webpack配置可以替换一下builder。 @angular-builders/custom-webpack和 ngx-build-plus都提供了对应的builder，查看npm的趋势custom-webpack用户比较多，这里以custom-webpack为例，介绍如何修改angular.json以用上自定义的webpack配置。

1.3 安装Builder的包

由于@angular-builders/custom-webpack并不是ng官方的包，所以使用前都需要先安装一下：

npm install @angular-builders/custom-webpack

不同的ng版本需要安装对应不同的版本的包， ng的大部分库目前有一个约定俗成的好习惯，就是主版本号和ng的主版本号是能够对上的。比如使用的是ng12，那就用custom-webpack@12的版本。那么为什么需要这么多版本，原因是ng在自己的不同版本下的默认使用的@angular-devkit/build-angular包的内容和结构甚至schema结构和位置可能会发生变化。对于custom-webpack来说更多是是继承build-angular的schema和代码，并暴露webpack的修改入口，让用户不需要了解整个webpack配置的情况下局部配置自己想要的功能。

1.4 配置方法

在angular.json文件中，替换@angular-devkit/build-angular为@angular-builders/custom-webpack, 主要包括browser、dev-server、karma等几个不同环节的builder，并增加配置参数

 "build": {
          "builder": "@angular-builders/custom-webpack:browser",
          "options": {
               // 以下为新增的配置 customWebpackConfig
               "customWebpackConfig": {
                     "path": "scripts/extra-webpack.config.js"
               },
              ....
           },
          "configurations": ...
 },

path可以按自己的工程来指定。 该文件可以导出一个函数（将会被调用）或者一段webpack配置（将会被Merge Options）。

从使用情况来说函数灵活性更好，可以直接操作整个webpack配置。示例文件内容

// extra-webpack.config.js
module.exports = (config) => {
    //  do something..
   return config;
};

至此，webpack的扩展配置所需要的基础步骤就完成了。

2 使用自定义Webpack配置案例-loader篇

2.1 案例1：使用PostCSS插件来处理CSS降级插值（主题化降级）

背景

组件库主题化采用了css-var方案进行主题化定制，通过运行时替换样式:root里的css自定义属性的值来达到变更主题色的功能。对于IE来说它不认识也无法解析带var的值，那么它会表现为无颜色。为了尽量满足渐进增强和优雅退化。我们需要做一些兼容，以便IE无法使用主题化的情况下也能正常显示颜色。

目标：

color: var(--devui-brand, #5e7ce0); 
-> 
color: #5e7ce0; color: var(--devui-brand, #5e7ce0);

上下文：

为了规范颜色的使用，库里使用的是scss变量来约束。如$devui-brand: var(--devui-brand, #5e7ce0), 本身这种写法是能满足现代浏览器的降级的，当找不到--devui-brand的css自定义属性，会回落到后面的色值，但是IE不认识var所以无法读出色值。组件的样式文件引用是定义文件然后直接使用$devui-brand作为值，如下

@import '~ng-devui/styles-var/devui-var.scss';
.custom-class {
  color: $devui-brand;
}

默认编译完为：

.custom-class {
  color: var(--devui-brand, #5e7ce0);
}

解决方案

既然已经知道目标了，那么这件事情就变得简单多了，通过插桩（console.log）查看默认NG工程启动的webpack配置，可以看到module里有两个rule是负责处理SCSS和SASS文件的， 它们都拥有test: /\.scss$|\.sass$/字段，一个负责全局的scss的编译（通过include字段指定了配置在angular.json的style的路径集合），一个负责全局以外的组件内引用的scss的处理（通过exclude字段排除了前面全局已经处理过的scss）。

通常第一个想法可能是处理sass，遇到$devui-brand的地方前面插入一句它的原始值。但是由于sass变量本身可能被二次赋值，如$my-brand: $devui-brand; color: $my-brand;，这时候遇到$devui-brand的就插值的显然不合适，重复的定义$my-brand只是会最后一个值生效。

换个思路，当scss展开为css之后，每个取值的位置就是确定的了，哪怕二次赋值的地方也是同一个终值了。这时候就可以采用脚本来写IE的降级，也就是目标所写的内容。

那么，我们可以再sass-loader处理完之后增加一个loader来处理这段css。对css的处理使用PostCSS能对语法结构进行走查更严谨。

最后修改代码如下：

// webpack-config-add-theme.js
function webpackConfigAddThemeSupportForIE(config) {
  [{
    ruleTest: /\.scss$|\.sass$/,
    loaderName: 'sass-loader'
  }, {
    ruleTest: /\.less$/,
    loaderName: 'less-loader'
  }].forEach(({ruleTest, loaderName}) => {
    config.module.rules.filter(rule => rule.test + '' === ruleTest + '').forEach((styleRule) => {
      if (styleRule) {
        var insertPosition = styleRule.use.findIndex(loaderUse => loaderUse.loader === loaderName
          || loaderUse.loader === require.resolve(loaderName));
        if (insertPosition > -1) {
          styleRule.use.splice(insertPosition, 0, {
            loader: 'postcss-loader',
            options: {
              sourceMap: styleRule.use[insertPosition].options.sourceMap,
              plugins: () => {
                return [
                  require('./add-origin-varvalue'),
                ];
              }
            }
          });
        }
      }
    });
  });
  return config;
};
module.exports = webpackConfigAddThemeSupportForIE;

代码大致逻辑为寻找test为less/sass正则的rule，在对应的use里的loader里找到less-loader/sass-loader的位置，然后在其数组位置前面增加一个postcss-loader，loader里使用了自定义的add-origin-varvalue的PostCSS插件。(备注：这里有一块逻辑是找到sass-loader的位置， 这里有两个等式是因为ng7，8和ng9用户的loader写法不一样了，之前ng7用字符串，后面ng9用的是文件路径)

PostCSS插件如下：

var postcss = require('postcss');
var varStringJoinSeparator = 'devui-(?:.*?)';
var cssVarReg = new RegExp('var\\(\\-\\-(?:' + varStringJoinSeparator + '),(.*?)\\)', 'g');

module.exports = postcss.plugin('postcss-plugin-add-origin-varvalue', () => {
  return (root) => {
    root.walkDecls(decl => {
      if (decl.type !== 'comment' && decl.value && decl.value.match(cssVarReg)) {
        decl.cloneBefore({value: decl.value.replace(cssVarReg, (match, item) => item) });
      }
    });
  }
});

代码的大致逻辑如下，通过postcss.plugin定义了一个插件，该插件遍历css每一条declarion(声明)，如果不是注释，且它的值（对于每一条css声明来说冒号左边称为property，postcss里为decl.prop；右边称为value，postcss里为decl.value）刚好匹配了正则规则（这里的正则规则为--devui-开头），则在这条规则的前面插入该规则且把值替换为原规则逗号后面的值。

最后挂载到extra-webpack-config里

// extra-webpack.config.js
const webpackConfigAddTheme = require('./webpack-config-add-theme');
module.exports = (config) => {
   return webpackConfigAddTheme(config);
};

至此我们达成了我们的目标，而且对插值的范围做了限定，限定为--devui开头的才需要插值，避免其他不想被处理的var被处理了。

要点：

• 找准CSS处理的位置, sass存在变量依赖问题，更适合在编译后的css文件里处理

• 掌握PostCss插件的简单写法， sourceMap选项维持不变

• 注意loader的处理顺序，是从use里的最后一个loader接收原始数据不断往前面的loader传递，最前面的loader负责了最后内容的呈现。

2.2 案例2： 读取配置上下文处理：SCSS/LESS 处理TS别名路径同步处理 （别名模块联调）

背景

组件库的demo对组件的引用，我们通过tsconfig里的alias实现了ts的别名引用，并在网站生产构建阶段采用了分开构建，先构建库，然后配置另外的tsconfig指向了构建完的库（不再直接指向源码）。

一方面使得demo看起来用法和业务一致，另一方面分开构建实现生产端组件库的demo的使用方法和业务使用方法完全一致，减少因为webpack构建和ng-packagr构建出来后一些细微差别导致问题没有提前暴露出来。

这些通过tsconfig和配置build的不同的configuration已经可以实现了，但是仅仅只适用于ts文件，导出的scss文件/less文件就不生效了（由于支持外部主题化变量使用，scss文件和less文件会导出）。

目标： sass、less文件实现ts别名一样的引用路径。

上下文：

现有angular.json里配置了两个configuration，一个是使用默认的tsconfig.app.json，一个是分开构建的tsconfig.app.separate.json。

angular.json如下：

tsconfig.app.json 继承了tsconfig.json有如下别名配置

{
   ....
"compilerOptions":{
    "paths": {
      "ng-devui": ["devui/index.ts"],
      "ng-devui
function lessReplacePathAlias(css, aliasMap, sourcePath) {
  const replacePathAlias = postcss.plugin('postcss-plugin-replace-path-alias', () => {
    return (root) => {
      root.walkAtRules(atRule => {
        if (atRule.import && atRule.filename) {
          const oFilename = atRule.filename.substring(1, atRule.filename.length - 1); // 去掉头尾单引号双引号 
          const rule = aliasMap.filter(rule => rule.aliasReg.test(oFilename)).pop();
          if (rule) {
            const prefix = rule.pathPrefixes[0]; // 取第一个路径忽略剩余的
            const filename = path.resolve(prefix, oFilename.replace(rule.aliasReg, (item, match) => match));
            const relativePath = path.relative(sourcePath.replace(trailingSlashAndContent, ""), filename).split(path.sep).join('/');
            var realPathAtRule = atRule.clone({ params: (atRule.options || '' )  + " '" + relativePath + "'", filename: "'" + relativePath + "'"});
            atRule.replaceWith(realPathAtRule);
          }
        }
      });
    }
  });
  return postcss([replacePathAlias]).process(css, { syntax: postcssLessSyntax }).css;
}

function process(source, map) {
  this.cacheable && this.cacheable();

  // 获取配置文件里的主题数据
  const aliasMap = getOptionsFromConfig(this).aliasMap;
  let newSource = source;
  if (aliasMap.length > 0) {
    newSource = lessReplacePathAlias(source, aliasMap, this.resourcePath);
  }
  // 返回结果
  this.callback(null, newSource, map);
  return newSource;
}

exports.default = process;

这里自定义一个wepack-loader的写法，实际上也是可以用postcss-loader搭配自定义replacePathAlias 的plugin 和 postcss-less的syntax进行使用。这里演示了wepack-loader的写法。

代码大意是定义了一个loader的optionSchema用于校验选项，process函数获取option里的路径别名数据之后，如果路径别名有数据则用postcss对代码进行处理。注意在process里this指向webpack的上下文，所以可以从resourcePath里获取当前文件路径。

代码核心为中间的postcss插件， 通过遍历@开头的规则，如果是一个import声明则读取文件名去掉头尾的单双引号；测试是否文件名命中了规则中的任意一条，命中则取第一条，和sass-loader处理的一样得到了文件的绝对路径，然后通过path.relative重新计算出和当前文件的相对路径。然后将这条@import规则替换成新的文件地址。

实际上这个思路同样适用于sass规则的处理，只需要把语法syntax换成postcss-sass。

我们可以看到前两个大案例都是在处理css类问题的，大部分时候处理都可以用上postcss利器。直接去操作css内容容易误修改内容，而经过AST语法树拆解后的遍历会更稳当一些。

说一下为什么会同时使用sass和less。一般工程是不会同时使用两种的。实际上我们的工程主要也是使用sass。但是对于一个打包后的组件库来说，业务使用的时候是不会感知它是sass还是less的，甚至也不会提供sass或者less文件给业务引用。这里是为了主题化的能力能够对外辐射，组件库同时提供了sass和less的版本变量供使用。

后记

这两个样式编译器loader支持路径别名的脚本最早写于2020年8月。

Webpack官方在sass-loader/less-loader的使用文档里面都说明了，~语法已经废除，建议删除。

sass-loader@11.0.0（2021-2-5），less-loader@8.0.0（2021-2-1）分别发布了对应版本声明~已经标记为Deprecated。

作为历史解决方案，这个案例依然会放在这里，提供一些解决思路。

笔者认为能~和现在的回落解决方案还是不一样的，尤其当存在同名文件的时候（目前这种情况会比较少，少有人使用模块同名路径作为相对目录路径），波浪线方案仍然能明显强调出文件的第一指向。

Webpack官方在2020年8月底开始给less-loader也加上了webpackImporter的选项，进一步屏蔽less-loader和sass-loader之间的差异。兼容历史原因，这两个loader目前还会保留波浪线语法。由于项目ng版本滞后于NG官方版本，NG官方版本使用的loader又滞后于webpack官方版本。目前NG9版本仍在用less-loader@5.0.0，sass-loader@8.0.2。

要点：

• 从运行时获取tsconfig配置项

• 文件路径处理（scss、less）

• 掌握loader的写法，接收参数。

更多解法补充

resolve.alias

Webpack配置中 config.resolve.alias 也是一个配置别名的地方， 而且sass-loader/less-loader也支持了webpackImporter的配置，其实可以直接通过修改config中的alias就能达成目的。 比如：

config.resolve.alias = {
      ... config.resolve.alias,
      'ng-devui': path.resolve('./devui/'),
   })

resolve.plugins：TsConfigPathsPlugin

那么如果webpack的resolve alias已经支持了，是不是tsconfig就可以不用配置，或者怎么配置成一份？

不幸的是 Angular工程的 webpack 和 tsconfig不是同步的，两边需要同时配置，否则会出现找不到模块的构建错误， 如果两者配置不同，隐患会更大，因为tsconfig的配置是直接影响tsc编译器的拿不到文件，webpack也会解读出一份等。

配置成一份可以通过写webpack-plugin在运行时拿到当前的tsconfig再处理数据塞到alias里。因为如果直接修改config，那么它是静态的，实际情况还是需要获取到ng工程当前的ts配置是什么文件会比较好。

Awesome-typescript-loader有个TsConfigPathsPlugin，使用也非常简单。

const { TsConfigPathsPlugin } = require('awesome-typescript-loader');
module.exports = (config) => {
  config.resolve.plugins = [
      ... (config.resolve.plugins || []),
      new TsConfigPathsPlugin()
   ]
};

给resolve.plugins塞一个TsConfigPathsPlugin就可以把tsconfig里的，不过这个插件已经存档了，最后一个版本是3年前的了。这里我们做了一个测试，仍然是不支持动态的tsconfig，它的代码可以参考用来写一个resolve的plugin， 动态的tsconfig的path获取可以参考我们之前的操作。

最后补充几个新的结论

• Webpack config的resolve.alias和 tsconfig的alias不是同步的，需要配置两份或者找到一个方法同步。

• Sass-loader 和less-loader的内部引用都能走webpack的resolve.alias， 可以说resolve.alias的解法会比 在改sass-loader的importer或者在less-loader前先处理 通用性更好，基本上所有blob都可以尝试去这样解决路径别名问题。更多需要注意的仍然是动态的tsconfig的配置获取问题。

2.3 案例3：修改TerserPlugin排除项，摇树处理问题（摇树问题）

背景

组件库的业务使用方刚升级ng7的时候，打包经常出问题，经常出现文件摇树之后，很多自执行命令被摇树认为无副作用摇树掉了。

目标：不关掉全局摇树的情况下，针对个别目录进行摇树的问题排除。

上下文：

Angular.json里有个配置，默认为打开，打开之后可以对js类型的代码进行摇树优化，从而减小打包体积。

Terser是从Uglifyjs这个库fork 出来的项目用来支持ES6语法，Angular 编译阶段用它来压缩js代码。

Angular使用TerserPlugin来进行摇树，由于装饰器等问题导致摇树效果不理想的问题（相关讨论内容见Angular摇树如何工作），angular提供了一个专门用于标记纯函数的注释的优化器，所以对于默认的Angular项目来说，摇树是一个两阶段模型。

第一个阶段是Angular在生产构建阶段(ng build --prod)在解析资源的时候加入了一个@angular_devkit/build_optimizer/webpack-loader，用于标记js文件里的无用代码；angular_devkit/build_optimizer 介绍它的主要功能为标记功能。

第二个阶段是Angular在生成打包的时候给Webpack配置了 optimization.minimizer数组塞入了TerserPlugin然后把无副作用的无引用代码摇掉。（准确说是塞入了两个Plugin，一个针对globalScript，一个排除globalScript。GlobalScript是指在angular.json的build的script字段配置的路径。）

解决方案

TerserPlugin本身是有一个include和exclude字段（见API）可以用正则和字符串来排除。

function terserOptionsWebpackConfig(config) {
  let excludeList = [
    // 此处可以填自己要排除的目录
  ]
  let minimizerArr = config.optimization.minimizer;
  let terserPlugins = minimizerArr
    .filter(plugin => plugin.options && plugin.options.terserOptions)
  terserPlugins.forEach(terserPlugin => {
    if (terserPlugin.plugin.exclude) {
      const isArray = Array.isArray(terserPlugin.plugin.exclude)
      if (isArray) {
        terserPlugin.plugin.exclude = [
          ...terserPlugin.plugin.exclude,
          ...excludeList
        ];
      } else {
        terserPlugin.plugin.exclude = [
          terserPlugin.plugin.exclude,
          ...excludeList
        ];
      }
    } else {
      terserPlugin.plugin.exclude = excludeList;
    }
  });
  return config;
};

module.exports = terserOptionsWebpackConfig;

之前在ng7工程会遇到比较多的摇树问题，有些升级到ng9之后默认配置有点变化之后就没有摇树问题了。包括IVY打包模式下编译引擎实际上摇树的方式不太一样，有些文件不会被摇掉了，这个问题还是要遇到具体问题具体分析来解决。必要时可以重新new一个TerserPlugin但是要保持它的原来的options不变。

要点：

• 摇树具体的阶段，拦截问题

• 维持原有的Options，不对其进行破坏。

2.4 案例4： 三方ES2015库自动babel化处理（仅有ES2015的库处理）

背景

highlight.js升级到10.0.0之后，官方就开始不再默认支持ie11了，导出的包也只有es2015的包。之前的业务需要为了兼容IE11，我们需要对highlight.js进行一次babel。更新到ng9之后，其实ng默认会仅打包es2015然后进行差分打包到es5，所以实际情况在生产打包是没有问题的，但是在本地开发的ie11调试环节会出现问题，比如class的语法ie不认识等等，导致整个js无法加载。

目标：让不支持es5的包在开发态支持es5。

上下文：由于之前组件库9的版在一段时间内仍然需要支持ie11，也就经常需要开发态下到ie11下debug，所以开发态下的highlight.js导致ie无法访问问题需要解决。

解决方案

首先es2015转es5经典的做法就是让babel帮忙处理。然后大部分的ES语法新增的api可以由core-js来解决，剩下的IE11还有一些浏览器端DOM的API的实现还需要添加一些polyfill才行。Polyfill可以用到了什么api就加什么api，具体可以从这里参考，本文不再累述。

// babel-loader-wepack-config.js
const path = require('path');
const ts = require('typescript');
const AngularCompilerPlugin = require('@ngtools/webpack').AngularCompilerPlugin;
const readConfiguration = require('@angular/compiler-cli').readConfiguration;
const ES6_ONLY_THIRD_PARTY_LIST = require('./es6-only-third-party-list');

function getAngularCompilerTsConfigPath(config) {
  const angularCompilerPlugin = config.plugins.filter(plugin => plugin instanceof AngularCompilerPlugin).pop();
  if (angularCompilerPlugin) {
    return angularCompilerPlugin.options.tsConfigPath;
  }
  return undefined;
}
function getTsconfigCompileTarget(tsconfigPath) {
  const {target} = readConfiguration(path.resolve(tsconfigPath)).options;
  return target;
}

function webpackConfigAddBabel2ES5(config, list = []) {
  const tsconfigPath = getAngularCompilerTsConfigPath(config) || 'tsconfig.json';
  const target = getTsconfigCompileTarget(tsconfigPath);
  if (target === ts.ScriptTarget.ES5) {
    config.module.rules.push({
      test: /\.js$/,
      use: [{
        loader: 'babel-loader'
      }],
      include: [
        ...ES6_ONLY_THIRD_PARTY_LIST,
        ...list
      ]
    });
  }
  return config;
};
module.exports = webpackConfigAddBabel2ES5;

// es6-only-third-party-list.js

const path = require('path');
const ES6_ONLY_THIRD_PARTY_LIST = [
    path.resolve('./node_modules/highlight.js') // ^10.0.0 no longer support ie 11
];
module.exports = ES6_ONLY_THIRD_PARTY_LIST;

两段代码大概思路就是从tsconfig里面读，如果目标为es5，则塞进去babel-loader，然后把对应的三方库的路径放到include里边。

ES6_ONLY_THIRD_PARTY_LIST 列表示意了highlight.js的路径应该怎么写。如果编译目标为es2015，则这段处理就不需要了不会被插入，哪怕是差分打包也不会调用它，ng-cli会自行调用内部逻辑。

后记

IE11已经慢慢退出了历史舞台，各大网站也开始声明不再支持IE11，这些冗余的插件已经可以慢慢移除。包括ng12起也不再承诺支持ie，升级到ng12之后这些插件也没有必要了。

要点：

• 分清语法API的降级和浏览器BOM/DOM垫片

• 提供一个可维护的列表

• 针对tsconfig的target上下文进行编译。

2.5 案例5： 拦截修改自动生成ts内容（内容自动扫描生成）

案例5-1： 自动扫描目录

背景

在可视化拖拽生产力平台项目，组件定义目录会有一系列重复雷同的目录结构，最后需要汇总到一个ts里作为全局信息入口。

目标：自动扫描组件定义目录，汇总信息到ts里，避免手动增加信息维护。

上下文：

生成的信息汇总内容结构为：

src/app/connect/connet.ts

目录的结构为：

src/component-lib

要求不要包含 _目录的内容

解决方案

const fs = require('fs').promises;
const path = require('path');

async function listDir() {
  return fs.readdir(path.resolve('./src/component-lib')).then(dirs => dirs.filter(item => !item.startsWith('_'))); // 过滤_开头的
}
function genConnectInfo(dirArr) {
  return `export const ConnectInfo = {
  ${dirArr.map(item =>"'"+ item +"': import(   'src/component-lib/" + item + "/connect')").join(`,
`)}
};`;
}
async function process() {
  var list = await listDir();
  return genConnectInfo(list);
}

module.exports = function(content, map, meta) {
  var callback = this.async();
  this.addContextDependency(path.resolve('./src/component-lib')); // 自动扫描目录，但是删除目录可能会引起报错
  process().then((result)=> {
    callback(null, result, map, meta);
  }, err => {
    if (err) return callback(err);
  });
};

const path = require('path');
function webpackConfigAddScanAndGenerateConnectInfo(config) {
    config.module.rules.push({
      test: /connect\.ts$/,
      use: [{
        loader: require.resolve('./scan-n-gen-connect-webpack-loader')
      }],
      include: [
        path.resolve('./src/app/connect')
      ],
      enforce: 'post',
    });
  
  return config;
};
module.exports = webpackConfigAddScanAndGenerateConnectInfo;

通过简单的一个loader 将目录扫描内容组装返回给src/app/connect/connet.ts。

这里有几个要点：

• 这里需要使用loader的enforce: 'post'属性，因为ts的编译最后loader是直接去文件系统读取内容的不是从上一个loader拿到结果继续往下处理的（不符合loader的规范，但是性能会更好），所以这里需要把阶段属性配置为'post'，确保最后编译的内容是我们生成的内容。

• 对loader添加一些依赖可以在目录结构变化的时候刷新内容，否则就只能等下一次启动的时候获取内容，即这一行 this.addContextDependency(path.resolve('./src/component-lib'));

• 由于webpack的tsc编译是文件分析依赖型的，我们动态生成的文件内容，webpack就无法从中分析依赖了另外一些ts内容，导致其他ts内容不会走ts编译。这时候可以参考下面，在tsconfing加一下include字段，解决编译问题。

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/app",
    "types": []
  },
  "files": [
    "src/main.ts",
    "src/polyfills.ts"
  ],
  "include": [
    "src*.d.ts",
    "src/component-lib*.ts"
  ]
}

要点：

• 自动扫描逻辑

• 添加依赖

• 添加非直接依赖的编译入口

案例5-2： 自动扫描css内容

背景

图标库导出了一系列可用字体图标，图标通过不同的css类名来引用，现在要做一个图标选择器，需要把所有图标列出来。

目标：分析icon.css，提取所有有效的icon名字。

上下文：

需要把信息自动生成到一个文件叫 src/app/properties-panel/properties-control/icon-picker/icon-library.data.ts

格式为一个数组

图标库的文件为./node_modules/@devui-design/icons/icomoon/devui-icon.css

格式为：

图片里红色标记的就是要提取出来的图标名。

解决方案

loader的定义

// auto-gen-icon-data-webpack-loader.js
const fs = require('fs').promises;
const path = require('path');

function genIconData(fileContent) {
  const iconNames = [...fileContent.matchAll(/\.icon-(.*?):before/g)].map(item => item[1]);
  return `export const ICON_DATA = [
  ${iconNames.map(item => "'" + item + "'").join(",")}
];
`;
}
async function process(file) {
  const content = await fs.readFile(`${path.resolve(file)}`, 'utf8');
  return genIconData(content);
}

module.exports = function(content, map, meta) {
  const file = './node_modules/@devui-design/icons/icomoon/devui-icon.css';
  var callback = this.async();
  this.addDependency(path.resolve(file));
  process(file).then((result)=> {
    callback(null, result, map, meta);
  }, err => {
    if (err) return callback(err);
  });
};

webpack config里塞入loader

const path = require('path');
function webpackConfigAddGenIconData(config) {
   
    config.module.rules.push({
      test: /icon-library.data\.ts$/,
      use: [{
        loader: require.resolve('./auto-gen-icon-data-webpack-loader')
      }],
      include: [
        path.resolve('./src/app/properties-panel/properties-control/icon-picker')
      ],
      enforce: 'post',
    });
  
  return config;
};
module.exports = webpackConfigAddGenIconData;

代码相对就比较简单了。

要点：

1、分析图标库文件结构，排除一些对齐的干扰项

2.6 补充：自定义Webpack配置loader的调试方法

• 配置项调试：在方法中进行打印调试， 通常在执行前就已经可以打印出配置项相关的内容。

• 内容调试：使用简单的loader打印前后经过loader的内容， 自定义一个打印内容的loader，在执行自定义loader前后都打印一下，可以获得对比内容。

• 一些经验： 修改loader的时候要注意本地开发阶段和生产打包阶段，不要顾此失彼。

  
  

文章介绍了如何在AngularCLI生成的工程里使用自定义的webpack设置，并且举了几个实际情况下为了解决问题修改的webpack配置，覆盖css的修改、js的修改以及拦截内容自动扫描生成。

本文主要为解决问题或者功能特性去修改webpack配置，没有涉及复杂的构建速度优化、性能优化等。

有些内容是旧版本处理IE11问题做兼容的，具体的实践不再具备复制方案就能解决现实问题的意义，更多的是提供一些思路和参考。

Webpack目前几个版本始终是从入口文件开始，通过规则配置对文件进行加载解析，通过插件拦截整个构建生命周期做一些抽取变换。

大部分时候Angular的默认配置已经能满足需求，当和三方库集成、自动化处理结合的时候，采用自定义的配置可以解决问题，节省工作甚至进一步优化性能等等。

看完上述内容，你们对如何自定义配置Angular CLI下的Webpack和loader处理有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注编程网行业资讯频道，感谢大家的支持。