网络编程

详解组件库的webpack构建速度优化
网络编程 2024/11/15 佚名
3 2

背景

在公司的主要工作是组件库（基于vue的ui组件库，类似element-ui）的开发，也已经有两个多月，期间一直觉得项目的开发构建太慢，每次开发打开开发环境需要 40s 左右，简直不能忍。前前后后尝试了各种优化手段，但是都不理想。终于在今天，找到了问题所在，构建速度提升了 50% 以上，现在只需要 17s 左右，整个心情都好了。现在记录一下所用到的各种优化手段，因为是开发环境，所以只考虑构建速度。

各种配置项的优化

主要是对一些loader添加 include exclude之类的小优化，其实这一点并没有带来多少性能的提升，只是一些安慰作用吧。

引入happypack

之前有看到相关文章介绍 happypack 采用多线程处理，能大大提升项目的构建速度。嗯，我觉得这个靠谱。看了下github上的文档，赶紧试试水。

修改webpack一些loader配置，使用happypack

// config.dev.js
{
 // ...
 module: {
  rules: [{
   test: /\.vue$/,
   loader: 'vue-loader',
   options: {
    // 这里估计是都懒得写lang='scss'
    css: 'style-loader!css-loader!sass-loader',
    // vue文件中基本不存在css代码，所以只把js交给happypack处理
    js: 'happypack/loader"_blank" href="https://github.com/QingWei-Li/vue-markdown-loader" rel="external nofollow" >vue-markdown-loader）等进行处理，配置都差不多，就不列出来了。


ok，配置完毕，赶紧跑起来试试水。结果就是报错了... oh no! 看了下官方文档说明，不支持 vue-markdown-loader。好吧，把 md 文件的处理改回去，再跑。嗯这次跑起来了，但是时间也就少了 4s-5s 左右，emmmmm，并没想象中多。


将运行的命令加上--progress能发现，主要耗时的就是处理 md 文件，很明显一遇到 md 文件进度条的跳动就慢下来了。


知道了，优化的主要目标应该是md文件的处理。


找到了 build/util.js 里面的一些处理，部分代码如下





function render(tokens, idx) {
 // tokens是markdown-it parse后的结果
 var m = tokens[idx].info.trim().match(/^demo\s*(.*)$/);
 if (tokens[idx].nesting === 1) {
  let index = idx + 1;
  var html = '';
  var style = '';
  var script = '';
  while (tokens[index].nesting === 0) {
   const content = tokens[index].content;
   const tag = tokens[index].info;
   if (tag === 'html') {
    html = convert(striptags.strip(content, ['script', 'style'])).replace(
     /(<[^>]*)=""("demo-box" :jsfiddle="${jsfiddle}">
    <div class="source" slot="source">${html}</div>
    ${descriptionHTML}
    <div class="hljs highlight" slot="highlight">
  `;
 }
 return '</div></demo-block>\n';
}







主要是将 tip 放到指定的 container 里。还有提取 tokens 里一些标记为html js css代码组成一个对象jsfiddle，传给一个 vue组件，用于提供jsbin的在线调试功能。利用markdown-it的 render方法，将其他采用markdown语法写的文档render成html代码放到指定div里面，将 html 代码（其实就是文档中的示例代码）作为slot分发给上面提到的 vue组件。


这里实在是没找到优化的手段。


引入dll




另外一个尝试的手段是，采用webpack的 DllPlugin 和 DllReferencePlugin 引入dll，让一些基本不会改动的代码先打包成静态资源，让 webpack 少处理一些东西


打包dll的配置





// config.dll.js
module.exports = merge(base, {
 // ...
 entry: {
  vendor: ['vue', 'vue-router', 'vue-i18n', 'clipboard']
 },
 output: {
  path: path.resolve(__dirname, './dll'),
  filename: '[name].js',
  library: '[name]_[hash]'
 },
 plugins: [
  new webpack.DllPlugin({
   name: '[name]_[hash]',
   path: path.resolve(__dirname, './dll/vendor.manifest.json')
  })
 ]
 // ...
})






上面配置打包会在 build 目录下生成 dll 目录，里面有 vendor.dll.js 和 vendor.manifest.json


然后在 config.dev.js 中，引入 DllReferencePlugin


DllReferencePlugin配置





{
 plugins: [
  new webpack.DllReferencePlugin({
   manifest: require('./dll/vendor.manifest.json')
  })
 ]
}






然后记得将打包好的js文件引入，这里可以采用add-asset-html-webpack-plugin





{
 plugins: [
  new AddAssetHtmlPlugin({
   filepath: require.resolve('./dll/vendor.js'),
   includeSourcemap: false
  })
 ]
}






这样，在项目中 webpack 处理 vue vue-router vue-i18n clipboard时，就不会去node_modules中拿了，会直接用 vendor.js


再次运行 npm run dev 发现时间也只少了 1s(我觉得其实是时间的小波动...根本不会少的) 毕竟大头不在这。


单组件的开发模式




后来突然想到，好像每次开发组件的时候，不都是单个单个来的吗，既然这样，我只处理指定组件的md文件，速度不就起来了吗。


嗯，这或许是个办法，试试水


找到引入 md 文件的地方，也就是 examples/route.js，部分代码如下





function loadDocs(path) {
 return r => require.ensure([],
  () => r(require(`./docs${path}.md`))
 );
}






这个是 vue-router 的动态加载，嗯，只要我把path给写成一个固定的路径（这里其实就是'/' + 组件名），不就能实现了吗。


运行命令大概是长这样的





// package.json
{
 "scripts": {
  "dev:component": "cross-env RUN_ENV=component node build/dev-server.js",
 }
}






由于在命令行中使用webpack-dev-server没有办法传递参数给process.argv，所以这里采用webpack-hot-middleware





// build/dev-server.js
const webpack = require('webpack');
const webpackConfig = require('./config.dev');
const express = require('express');

webpackConfig.plugins = webpackConfig.plugins || [];

// 全局开发模式采用webpack-dev-server 无需配置hmr，这里需要单独给上
webpackConfig.plugins.push(new webpack.HotModuleReplacementPlugin());
webpackConfig.entry.push('webpack-hot-middleware/client"htmlcode">



const component = process.argv[2];

// 先判断一下是不是单组件开发模式，是的话，必须指定运行的组件
if (process.env.RUN_ENV === 'component' && !component) {
 throw new Error('component is required, like: npm run dev:component slider');
}

// 然后通过DefinePlugin写入
// 对了这里有个要注意的点，path是个变量，不是字符串，所以不能是"'path'"，真tm机智。
// config.dev.js
{
 // ...
 plugins: [
  new webpack.DefinePlugin({
   'process.env': {
    NODE_ENV: "'development'",
    RUN_ENV: process.env.RUN_ENV === 'component' "'component'" : "''",
    component: process.env.RUN_ENV === 'component' "text-align: center">详解组件库的webpack构建速度优化


好像是 webpack 不能正常的处理，最后是改成了下面这样才能正常工作





function loadDocs(path) {
 return r => require.ensure([],
  () => {
   if (process.env.RUN_ENV === 'component') {
    r(require(`./docs${process.env.component}.md`));
   } else {
    r(require(`./docs${path}.md`));
   }
  }
 );
}






另外，除了md文件只需要处理一个组件的之外，组件源码也有很多是不需要处理的，所以，继续修改下代码


应用的入口处将全局引入ui库的方式换成按需





// 原来的代码
import Vue from 'vue'
import gsui from 'components'
// ...
Vue.use(gsui)









// 修改后的
import Vue from 'vue'
// ...

if (process.env.RUN_ENV === 'component') {
 // 一些页面共用的组件
 // 只能用require 不能import 因为是静态处理
 Vue.use(require(`components/submenu`).default);
 Vue.use(require(`components/menu`).default);
 Vue.use(require(`components/layout`).default);
 Vue.use(require(`components/menu-item`).default);
 Vue.use(require(`components/header`).default);
 Vue.use(require(`components/icon`).default);
 Vue.use(require(`components/tooltip`).default);
 Vue.use(require(`components/modal`).default);
 Vue.use(require(`components/message`).default);

 Vue.use(require(`components${process.env.component}`).default);
} else {
 // 不是单组件开发模式引入全部
 Vue.use(require('components').default);
}





优化后的单组件开发模式和全局开发模式的对比


详解组件库的webpack构建速度优化


详解组件库的webpack构建速度优化


但是很快就感到不实用，因为有很多组件是需要依赖其他组件的，有时候需要看其他组件的文档，单组件模式就没法做到了


只能再找别的手段了


意外发现，原来是vue-loader的版本原因带来的性能消耗




前天也不知道在哪发现了一个UI库at-ui，下意识点进去看了下他们的构建配置，发现和我们的很像（其实webpack配置也都差不多的），也是用了 vue-markdown-loader ，出于好奇，clone了下来本地构建了一下。结果出乎意料，他们的构建只需要 16s 16s 16s 怎么会差这么多，看了下他们的文档，还是中文和英文双份的（我们的组件库暂时没有英文文档），虽然组件没有我们的多，但是文档绝对是多几十个的，而且耗时不也是在md文件的解析上吗(再次问号脸)。再仔细看了他们的配置和对md文件的处理，确实对md文件的处理代码会少很多，但是这是因为支持的写法不同，而且也不至于导致时间相差那么多。


找不出原因，干脆用他们的配置来构建我们的项目试试看吧。把build目录完全copy了过来，修改了一点配置如 entry alias，安装一些这边不存在的依赖，其他基本都不需要动了，总之跑起来看看。


磕磕碰碰修改几个报错问题后，跑起来了，但是时间还是没变(37s)，奇了怪了。再试试另一种，用我们的配置去跑他们的项目看看。


把他们项目的src和docs目录copy了过来，同样把我们的配置修改一些配置 entry alias 再加点loader，他们需要处理yml文件，跑起来看看。结果更纳闷了，时间是40s（再次问号脸）。最后在我们的项目中，用他们的配置去跑他们的项目，我这想验证一件事，会不会是某个依赖的版本不同引起的，结果确实是这么回事...


接下来就是找出是哪个依赖带来的了，这里需要注意一点package.json中依赖的版本 如^1.0.0，以 ^ 开头的依赖，安装时总是会按照这个大版本下的最新版本的 也就是 ^1.0.0 ^1.1.0 都是装 1.x 下的最新版本。而 ^1.0.0和^2.0.0 才是不一样的。最后主要尝试的几个不同版本依赖主要有 webpack(2.x和3.x) vue-markdown-loader(1.x和2.x)，但是这两个换掉之后还是很慢，最后在同事的提醒下，可能是 vue-loader 因为 vue-markdown-loader 是依赖 vue-loader的，而且无论是 1.x还是2.x 都是用的 vue-loader 12.x 的版本，而我们用的是 13.x 最后功夫不负有心人，是从 vue-loader 的 v13.1.0 开始， 构建速度会变慢。


变慢的原因




下面这个结果是公司的一位牛人发现的


最后发现是 v13.1.0 以上的 vue-loader 采用 prettier 来格式代码，替代了原来的 js-beautify， 是这个导致了性能问题。


最后的配置





// config.base.js
module.exports = {
 module: {
  rules: [
   {
    test: /\.css$/,
    use: [
     'style-loader',
     'css-loader',
     {
      loader: 'postcss-loader',
      options: {
       config: {
        path: utils.resolve('./postcss.config.js')
       }
      }
     }
    ]
   },
   {
    test: /\.md$/,
    loader: 'vue-markdown-loader',
    options: {
     use: [
      utils.mdAnchor,
      utils.demoContainer,
      utils.tipContainer
     ],
     preprocess: utils.mdPreprocess
    }
   },
   {
    test: /\.scss$/,
    use: 'happypack/loader"htmlcode">



// config.dev.js
module.exports = merge(config, {
 entry: entry,

 output: {
  path: '/',
  publicPath: '',
  filename: '[name].js'
 },

 plugins: [
  new webpack.DefinePlugin({
   'process.env': {
    NODE_ENV: "'development'",
    RUN_ENV: process.env.RUN_ENV === 'component' "'component'" : "''",
    component: process.env.RUN_ENV === 'component' "text-align: center">详解组件库的webpack构建速度优化


结语




最后发现是依赖版本带来的构建性能问题，不能算是webpack构建的优化。算是一个踩坑吧


其他在项目中可以用到的优化点应该主要就是 happypack dll了，能够有效的提升构建速度，其他还需要多多尝试




以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。


                                

                                

                                     

                                

                                    标签：
                                        
webpack构建速度,webpack构建速度优化

                                     

                            

                        

                        

                            

                                免责声明：本站文章均来自网站采集或用户投稿，网站不提供任何软件下载或自行开发的软件！
                                如有用户或公司发现本站内容信息存在侵权行为，请邮件告知！ 858582#qq.com
                            

                        

                        

                            
                            
                        

                        
                        
无争山庄资源网 Copyright www.whwtcm.com

                        

                            

                                
                                
                                    评论“详解组件库的webpack构建速度优化”
                                
                            

                            

                                

                                    
                                    

                                    

                                        
暂无“详解组件库的webpack构建速度优化”评论...
www.whwtcm.com 无争山庄资源网
129,905影音资源
244,626技术资源
111,817软件资源
578,645站长资源

更新日志

友情链接

杰晶网络 DDR爱好者之家 桃源资源网 杰网资源 富贵资源网 南强小屋 铁雪资源网 幽灵资源网 万梅资源网 狼山资源网 白云岛资源网 昆仑资源网 相思资源网 明霞山资源网 内蒙古资源网 黑松山资源网 茶园资源网 饿虎岗资源网 大旗谷资源网 常春岛资源网 岱庙资源网 兴国资源网 快活林资源网 蝙蝠岛资源网 帝王谷资源网 白云城资源网 伏龙阁资源网 清风细雨楼 天枫庄资源网 圆月山庄资源网 无争山庄资源网 神水资源网 移花宫资源网 神剑山庄资源网 无为清净楼资源网 金钱帮资源网 丐帮资源网 华山资源网 极乐门资源网 小李飞刀资源网 凤求凰客栈 风云阁资源网 金狮镖局 鸳鸯亭资源网 千金楼资源网 更多链接
无争山庄资源网 Copyright www.whwtcm.com