1. 编程号首页

webpack4 搭建企业级脚手架

编程小号 • • 未分类

webpack4 搭建企业级脚手架eval模式，构建速度很快，可以得到错误在源代码中的行列，但是无法查看具体的行列信息， 因为它无法查看源代码，只能查看转换后的代码。 cheap-module-eval-source-map 和 cheap-eval-source-map 类似，但是是loader转换之前的源文…

前端模块化

commjs使用同步的方式去加载模块，使用module.export导出，require引入，commjs适合用于在服务端， 因为服务端读取磁盘文件较快，commjs同步的特性让其在编译完成就可以使用模块了。commjs的加载机制是 require的值是module.export的值的拷贝， amd和cmd都是使用的异步的加载机制，主要用于浏览器端。 es6模块是ECMA 提出的javascript模块化的规范，将会成为一种通用解决方案。 commjs的加载方式是运行时加载， import是编译时加载， 编译时加载可以做指定输入，编译阶段做ast语法树解析可以进行摇树优化，还可以做静态优化的方案，而运行时加载则不能，因为tree-shaking的基础就是需要做静态分析的。

项目构建工具

市面上有很多如rollup，webpack， glup还有Parcel。 rollup专注于处理es mudule的处理，如果要实现其他模块的打包会比较繁琐和复杂，对一些splictChunk的方式支持的并不友好，不支持HMR, rollup更加精而美，如vue、react这些类库的源码都是通过rollup进行构建。相比较来说， rollup更适合类库的搭建，而webpack适合所有项目的构建。 Parcel构建工具在一定意义上实现了零配置即可快速构建项目。配置过程依赖自动安装，而且自带多进程工作方式。但是还是更加推荐webpack，因为webpack是目前为止最好的构建工具， 在知名度，生态环境，插件市场，还有开发人员的熟知度。这每一点都无比的重要，而webpack是在每个点上都做到数一数二的水平，除了它的官方文档以外。

构建工具的作用

打包各种类型的资源， 将代码中分散的js打包到bundle.js中，将一些新特性的语法转换为载体(浏览器)可以识别的语法， 代码转换，文件优化，代码分割， 模块合并， 自动刷新， 代码校验， 自动发布。 构建让开发流程更加自然，合理的构建让开发效率更加高效，提高效率和生产力， 目前的webpack还需要手动构建， 希望等到以后会出现一套集成的通用方案，接口暴露的更彻底，更友好。 就像以前的java开发使用ssm开发项目，需要进行一大堆的配置，配置过程痛苦而且繁琐，到了springboot的时代，就没有那么繁琐的配置了。前端构建工具的发展也会随着一系列的技术迭代而越来越友好。

了解webpack

webpack4提供了webpack-cli 启动webpack，而此时webpack也可以进行零配置。会给一些必要的配置设置默认值。比如entry默认src/index.js， output默认build/main.js。

webpack的配置文件通过webpack.config.js进行修改，配置文件使用commonjs的方式导出配置数据。

mode模式

mode模式， develpoment 和 production webpack会根据开发模式的不同进行不同的项目优化， 而配置人员要针对不同的环境进行不同的构建流程， 开发环境需要添加一些辅助开发工具和开发打包的一些优化方案，而生产环境则更注重于体积的减小和压缩模块的拆分与公用。

入口和出口

入口和出口，入口指定了从哪个文件开始来进行构建，bundle是webpack将所有在代码中零散的模块进行统一打包，打包到一个bundle中，这个bundle的输出位置和其他输出信息。而输出位置信息必须是一个绝对路径。

打包后的模块是一个自执行函数，传入的参数是一个对象，key是打包文件的路径，值是一个函数，使用eval函数执行其内部逻辑。

webpack4 搭建企业级脚手架

  • webpack为每一个模块会标识一个moduleId, 所以我们重复引用的时候并不会进行重复打包，就是多执行一次__webpack_require__(moduleId)拿到installedModules这个中的module cache

context配置

context 配置，context的值是一个路径， 该路径是entry的相对路径也是html-webpack-plugin的相对路径， 也就是说当我们在context上下文中配置了一个路径，那么entry与htmwebpack-plugin的路径就是基于该路径的，

resolve配置

resolve配置 可以用来配置别名，当在代码中使用import 引入某个文件的时候可以使用这个别名进行路径的匹配。还可以对引入文件的扩展名进行简写，比如引入import ../index.js可以简写为 import ../index

resolve: {
    extensions: ['.js', '.vue', '.json'],
    alias: {
        'vue$': 'vue/dist/vue.esm.js',
        '@': resolve('src'),
    }
},

对媒体资源进行打包

对一些媒体资源进行打包，使用url-loader，也可以使用file-loader，但是url-loader几乎有file-loader的所有功能，还可以配置超过一定大小转换base64， 在url-loader的name属性中有可以让我们自定义文件输出的路径，可以进行对打包后文件的分类和管理。name的值就是打包过后的文件路径和文件名称，文件名称使用[name]占位符进行替代，文件类型使用[ext]占位符替代 这里的媒体资源一般指

        // 注意这里打包图片的时候，要设置esModule: false，是版本问题，不然会报错。 
        png|jpe?g|gif|svg
        mp4|webm|ogg|mp3|wav|flac|aac
        // 注意如果你使用了elementui的话，这里是woff， 而不是woff2， 因为element-ui/lib/theme-chalk内是没有woff2文件的。
        woff|eot|ttf|otf

例如：

{
    test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
    loader: 'url-loader',
    exclude: [resolve('src/icons')],
    include: [resolve('src')],
    options: {
        esModule: false, // 版本问题
        limit: 8192,
        // 自定义目录和名称
        name: utils.assetsPath('img/[name].[hash:7].[ext]') // 打包后的文件会输出到指定目录的img/[name].[hash:7].[ext]
    }
},

对svg的打包使用svg-sprite-loader

devServer的配置

在development模式中的配置，devServer是非常重要的一个辅助开发工具，提供HMR， gzip压缩，使用http服务运行，自动打开浏览器，跨域代理，对控制台的输出控制，静态资源的路径一系列的功能， 使用devServer开启的服务并没有产出任何文件，devServer将打包后的结果存放到内存中，在内存中进行对文件的读取， 极大的提高了效率。devServer内部也是内置了一个express服务器， devServer的contentBase放置没有被webpack打包的文件，但是如果也需要进行访问的静态资源目录，而且使用服务器路由进行指向，不需要太多文件的输入和输出操作。

 devServer: {
    clientLogLevel: 'warning',
    historyApiFallback: {
        rewrites: [
            { from: /.*/, to: path.posix.join(config.dev.assetsPublicPath, 'index.html') },
        ],
    },
    hot: true,
    contentBase: false, // since we use CopyWebpackPlugin.
    compress: true,
    host: HOST || config.dev.host,
    port: PORT || config.dev.port,
    // open: config.dev.autoOpenBrowser,
    overlay: config.dev.errorOverlay
        ? { warnings: false, errors: true }
        : false,
    publicPath: config.dev.assetsPublicPath,
    proxy: config.dev.proxyTable,
    quiet: true, // necessary for FriendlyErrorsPlugin
    watchOptions: {
        poll: config.dev.poll,
    }
},

对样式文件进行打包

webpack对于loader的处理是自下而上的，在处理.css文件时，使用了两个loader css-loader和vue-style-loader(style-loader)，这里用的是vue项目，而要解析.vue文件中的style样式，要使用vue-style-loader进行处理。 如果对于预处理样式文件的话，比如sass文件， 在加上sass-loader处理一遍再给css-loader….。

关于cache-loader的坑

在后面优化的时候，使用了cache-loader进行优化，cache-loader的用法就是写在loader的最前面，然后进行cache-loader解析，如果没有改变的，直接从磁盘上拿文件，极大提升了效率，但是解析和读取文件的过程也需要时间，所以如果是性能开销极大的loader选择cache-loader进行处理的话，会显著的提高打包效率。但是如果遇到了mini-css-extract-plugin.loader的话，还是将cache-loader放在mini-css-extract-plugin.loader的前面，那么根本就不会去打包样式，去cache-loader的issues中找到了这样一个issue github.com/webpack-con… 你要将cache-loader写在mini-css-extract-plugin.loader的后面。

  • ps

如果插入太多的style样式会导致页面阻塞，所以使用mini-css-extract-plugin对样式进行提取。但是在开发环境中，我使用mini-css-extract-plugin无法进行css热更新，网上找了几种办法未解决，使用了style标签的形式可以进行热更新。在生产环境中使用mini-css-extract-plugin。

对js文件进行打包

webpack默认只能处理js和json， 而对于js的处理又是重中之重，我们需要把js转换成es2015， 转换jsx语法，对一些类的静态方法需要进行polyfile， 对于generator语法的处理，js的分包，懒加载机制都是js文件需要做的，通过babel他们变的简单了。像一些通过@babel/ployfile不仅体积很大，而且会污染全局的沙盒环境，很不推荐。这里使用core-js进行对类的方法进行polyfile

    {
      "presets": [
        [
          "@babel/preset-env",
          {
            "useBuiltIns": "usage", // or "usage"
            "corejs": 3
          }
        ]
      ],
      "plugins": [
        "transform-vue-jsx",
        "@babel/plugin-transform-runtime",
        "@babel/plugin-syntax-dynamic-import"
      ]
    }

因为js模块较多，就采用了多线程打包的方案，对js文件进行多线程打包，这里视情况而定，有些项目不一定需要多线程打包，因为分配线程需要消耗一定的资源，
如果电脑性能好，开的进程少，那么打包的速度就会提高，反之会降低。
happypack的使用很简单，匹配到js文件，使用happypack进行打包，指定id，该id会去找plugin中的HappyPack中的id，

对于js使用cache-loader，发现会很大程度上提高打包的速度，配合happypack大概提高8s左右的时间，
这里的时间不是固定的，是根据项目的大小和复杂程度来的，在一定程度上成正比。

const happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length });
new HappyPack({
    //用id来标识 happypack处理那里类文件
    id: 'js',
    //如何处理 用法和loader 的配置一样
    loaders: [
        {
            loader: 'cache-loader'
        },
        {
            loader: 'babel-loader?cacheDirectory=true',
        }
    ],
    //共享进程池
    threadPool: happyThreadPool,
    //允许 HappyPack 输出日志
    verbose: true,
}),

关于happypack对vue文件的多线程打包
vue-loader 15现在不支持happypack 因为happypack内部使用了虚拟的compiler和loaderContext，不建议使用happypack了，

热模替换

永远不要再生产环境下使用HMR， 所以我们只在开发环境中配置。

  • 所谓的热模替换，即对模块进行热插拔，当更新的时候只对变化的模块进行更新，而不会干扰到程序的整体运行流程和全部刷新，我们知道刷新意味着内存中数据丢失，需要重新获取资源，在很多场景中，HMR都很重要。
 // devserver中配置
 // 开启 HMR 特性，如果资源不支持 HMR 会 fallback 到 live reloading
 hot: true,
 // 表示不会回退到 使用刷新的方式进行重载
 // hotOnly: true
 
 // 配置hmr所需要的插件
 new webpack.HotModuleReplacementPlugin(),
  • 对于一般的css和img，hmr开箱即用，但是对于js，hmr却无法进行通用方案的支持。因为js导出模块的不确定性和引用的不确定性，hmr无法对其进行通用的处理方案。如果要对js进行进行热模替换的话,则需要HotModuleReplacementPlugin提供的api进行手动的处理需要进行hmr的模块。但是所幸我们使用的是框架，不管是vue还是react都集成了hmr的方案，他们会让这些js模块进行统一处理，加上moudle.hot方法进行判断。我们只需要开箱即用。在vue中 vue-loade 内部使用的 vue-hot-reload-api会集成进去热重载方案，如果使用原生js的话，那么就需要我们进行手动的对js进行热莫替换， 框架做了一套集成的方案，同样对于模块的导出方式和数据结构也是规定好的，这就是为什么框架这么方便的集成一套通用的热模替换方案。

配套插件

// 重载之后在控制台显示的file name 是更新的文件的名字，默认的是文件的id
new webpack.NamedModulesPlugin(),

sourcemap

  • 在webpack中 sourcemap的模式的要使用devtool进行开启， 这里官网上已经说的很详细了，

     补充几个小点：eval模式放在一个临时的虚拟机中运行，VM154:1 //

webpack4 搭建企业级脚手架

  • 每段代码都会通过sourceURL进行声明 webpack4 搭建企业级脚手架

  • eval模式，构建速度很快，可以得到错误在源代码中的行列，但是无法查看具体的行列信息， 因为它无法查看源代码，只能查看转换后的代码。

  • source-map模式 ， 会产生.map文件，将打包好的文件通过.map文件可以映射到源文件，

  • eval-source-map 可以定位文件，而且可以定位具体的行列信息(因为可以生成source-map映射文件)，

  • cheap-eval-source-map 可以定位文件，但是无法定位到具体的列，只能定位到具体的行，而且是loader转换之后的代码，但是构建速度得到提高

  • cheap-module-eval-source-map 和 cheap-eval-source-map 类似，但是是loader转换之前的源文件代码。

在开发环境中devtool一般情况下项目的最适合的选择的是cheap-module-eval-source-map 他的打包和构建速度可以，而且会产品源代码，可以进行调试，生产环境使用false，构建和打包速度最快，不会产生源代码和其他额外文件。如果在生产环境中出现了bug，而其他环境中没有这个bug，想要定位而且还不想暴露源代码的话，可以使用nosources-source-map

开发环境优化

dll优化： 在项目中，我们通常会使用到一些第三方包，而且这些第三方包版本固定，不会迭代更新，而我们每次打包都要这些第三方包进行打包，很浪费时间，所以开发环境我们使用dll链接库进行对一些固定的文件进行先行打包，然后使用manifest进行引入，我们先新建dll_webpack配置文件(配置development模式), 然后在开发环境需要的webpack配置文件中使用webpack自带的DllReferencePlugin插件进行桥接已经打包好的第三方资源。 我们需要在index.html中手动引入已经打包好的dll.js文件，我们可以通过AddAssetHtmlPlugin插件将打包好的js文件动态的导入到index.html中

// webpack.dll.config.js
const webpack = require('webpack')
const utils = require('./utils')
const config = require('../config')
const path = require('path')

module.exports = {
  mode: 'development',
  entry: {
    hk: ['vue/dist/vue.esm.js', 'vuex', 'echarts', 'vue-router', 'element-ui']
  },
  output: {
    filename: '_dll_[name].js',
    // path: path.resolve(__dirname, 'dll'),
    path: path.resolve(__dirname, 'dll'),
    library: '_dll_[name]',
    // libraryTarget: 'var'
  },
  plugins: [
    new webpack.DllPlugin({
      name: '_dll_[name]',
      // path: path.resolve(__dirname, 'dll', 'manifest.json')
      path: path.resolve(__dirname, 'dll', 'manifest.json'),
    })
  ]
}
// webpack.config.js
// 将dll链接库的内容放到html中
new AddAssetHtmlPlugin({ filepath: require.resolve('./dll/_dll_hk.js') }),
new webpack.DllReferencePlugin({
    manifest: path.resolve(__dirname, 'dll', 'manifest.json')
}),

生产环境优化

使用mini-css-extract-plugin时压缩代码

 当使用mini-css-extract-plugin进行提取css文件时， css文件不会被打包， 我们可以使用在minimizer中使用optimize-css-assets-webpack-plugin 进行压缩css代码，但是当使用minimizer属性的时候，webpack就会认为你不再使用默认的压缩方式了，而是使用自定义的压缩方式。所以还要手动的添加webpack内置的压缩js的插件terser-webpack-plugin

optimization: {
    minimize: true, // production模式会自动开启摇树优化 usedExports 和 minimize 和 sideEffects 
    splitChunks: {
        chunks: "all",
        minSize: 16000, // 模块的最小体积
        minChunks: 1, // 模块的最小被引用次数
        maxAsyncRequests: 5, // 按需加载的最大并行请求数
        maxInitialRequests: 3, // 一个入口最大并行请求数
        automaticNameDelimiter: '~', // 文件名的连接符
        name: true,
        cacheGroups: { // 缓存组
            vendors: {  //第三方
                test: /[\\/]node_modules[\\/]/,
                priority: -10//权重
            },
            default: {
                minChunks: 2,
                priority: -20,
                reuseExistingChunk: true
            }
        }
    },
    minimizer: [
        new TerserJSPlugin({
            cache: true, // 是否缓存
            parallel: true, // 是否并行打包
            sourceMap: false // 是否开始源码映射
        }),
        new OptimizeCSSPlugin({})
    ],
},
  1. tree-shaking 摇树优化 摇树也就是将晃动将树上的枯黄的树叶让其掉落下来，形成一颗新树。 而webpack会将那些未被引用的代码通过摇树优化进行去除。tree-shaking配合optimization 选项开启minimize会自动压缩掉未被使用的代码。 对于webpack来讲，并不是所有的模块代码都可以被tree-shaking，一个较典型的就是loadsh，如果你引入了loadsh，只用了其中一个方法，webpack仍然会将loadsh其他的方法全部打包，tree-shaking失效了，因为loadsh默认的导出方式是commonjs，而tree-shaking的前提就是模块是esModule。
  2. scope hoisting 如果没有scope hoisting的话，打包之后在一个自执行函数中会存在一些变量，这些变量的作用就是经过一系列的计算对另外一个结果产生影响。而这些东西运行在浏览器端会消耗内存进行存储，有可能还会产生大量的闭包(需要规定函数作用域)造成内存消耗，而scope hoisting可以将这些静态放在一个作用域中，进行合并计算。减少了打包的体积和减少了内存的开销。
  3. splitChunks 对代码进行分包， splitchunk会将我们项目中的资源模块按照设计的规则打包到不同的bundle中。 在项目中主要用到的就是与ESModules 的动态导入特性相结合，按需加载模块。而且能对代码公共部分进行提取。对第三方vendors和业务代码进行提取

今天的文章webpack4 搭建企业级脚手架分享到此就结束了，感谢您的阅读。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/16798.html

赞 (0)
编程小号编程小号
0

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注