• webpack CommonsChunkPlugin


    最近的项目使用webpack 做依赖管理和打包, 为了尽量重用代码, 使用了CommonsChunkPlugin插件来分离共用代码。

    项目后端是Asp.net MVC, 为了尽量符合框架的使用理念, 前端代码的构建以编译ES6 和 Sass 文件(不压缩)为目标。为了让后端可以直接运行项目, 编译出来的文件也放在了仓库中。 (这是引出问题的原因,如果构建优化流程全在前端做的话就没有下面的问题了)

    一开始的webpack配置是这样的 

     1 let commonsPlugin = new webpack.optimize.CommonsChunkPlugin({
     2     filename: "common.js"
     3 });
     4 
     5 
     6 let plugins = [
     7     commonsPlugin,
     8 ];
     9 
    10 module.exports = {
    11     plugins: plugins,
    12     // ...
    13 }

    这样的用法, webpack会在每次打包的时候找出所有entry 所共用的部分抽取出来成为 common.js 文件。

    但是在之后的多人合作开发中遇到了很多次merge conflict 的情况, 因为不同的entry文件的修改都有可能导致common.js内容的变化, 进而使得webpack 的 import 引用id 变化, 然后影响到其他所有的entry 输出文件。 冲突的情况基本会影响到所有的输出文件, 处理起来很是麻烦。

    后来重新读了一遍CommonsChunkPlugin 找到了一个不错的解决方案, 简单的说就是显示申明公共依赖而不用webpack来自动计算。

    这样修改后, 各个entry的修改只会影响到自己的输出文件,不会影响到全部的输出。 唯一需要注意的是公共entry文件的改动需要通知其他人先提交代码做好同步, 然后再做改动(而且如果只是修改依赖的内容并不会影响到其他文件, 之后添加或者减少依赖才会有影响), 可以最大限度消除conflict

    参考url : https://webpack.js.org/plugins/commons-chunk-plugin/#explicit-vendor-chunk

    代码稍作修改:

     1 let commonsPlugin = new webpack.optimize.CommonsChunkPlugin({
     2     // reference: https://github.com/webpack/webpack/tree/master/examples/two-explicit-vendor-chunks
     3     // to make the vendor static, reduce the chance of conflicts.
     4     names: ['vendor'],
     5     minChunks: Infinity
     6 });
     7 
     8 let plugins = [
     9     commonsPlugin,
    10 ];
    11 
    12 module.exports = {
    13     plugins: plugins,
    14     entry: {
    15         vendor: ['./common/app.js'],  // 此处管理所有公共依赖
    16         shared_official: "./views/shared/official-site.js",
    17         home_experimental: "./views/home/experimental.js",
    18         home_index: "./views/home/index.js",
    19         course_smallstars: "./views/course/smallstars.js",
    20         course_trailblazers: "./views/course/trailblazers.js",
    21         course_highflyers: "./views/course/highflyers.js"
    22     }
    23 }

    修改完之后就可以让输出文件愉快的和后端框架一起玩耍了。

    (完)

  • 相关阅读:
    内部类概述和访问特点
    权限修饰符 权限
    抽象类和接口作为返回值类型的问题
    抽象类和接口作为形参问题
    jdbc:java数据库连接
    类与类、类与接口、接口与接口的关系
    接口
    抽象类
    多态
    继承中构造方法的关系
  • 原文地址:https://www.cnblogs.com/tangkikodo/p/7017651.html
Copyright © 2020-2023  润新知