基于webpack搭建前端工程解决方案探索 about chemdemo.github.io

[fouber]

看过很多号称使用了webpack的项目，基本上无外乎这么几种最终运行效果：

• 图省事，一个大bundle（呵呵）
• 一个页面一个chunk，公共资源冗余重复合并在各个chunk中（呵呵）
• 刚好页面彼此很独立，完全没有公共资源（算你走运）

正如 @kerryChen95 在我的blog底下留言说到的：

以Webpack目前对WebApp架构支持的完善程度，它只差一步就能实现WebApp和WebSite（暂且这么叫，就是传统的服务端模板生成页面的意思）的通吃，只要它实现了生成资源表的API（前提是Webpack认同 资源表+资源加载框架 这种理念），然后，如果业界出现了某种资源表的事实标准，那么就一切就完美了~

我觉得这种认识是早晚的，因为优势太明显了吧。。。

此外，我还想吐槽webpack的一些设计：

1. require的返回结果只有三种情况：

   • 返回文件uri——资源定位
   • 返回文件内容（文本或base64）——资源内嵌
   • 什么都不返回，只是在表中记录资源依赖关系（如果认可）——依赖声明

   除了以上三种情况，前端构建不再需要多余的规则了。而返回文件内容时到底该返回文本还是文件base64是可以被唯一确定的，只要给出被require的文件就知道该返回哪种了。所以我觉得webpack还可以在精进一步概念。

2. 这个require标识可以扩展到html和css。有些技术选型的情况下我们可能也需要在html或者css中标记依赖或者资源定位，比如模板中可能直接写一个img src定位资源（当然，你可以准换成js中定位然后模板传值给html）。

在三种语言中分别提供资源定位、资源内嵌、依赖声明的构建标识，采用表+资源加载框架优化加载，以上这两点构成了fis的核心设计理念，不可否认webpack是目前最接近fis的构建工具

[fouber]

一般webapp是有一个物理页面，然后根据hash或者url加载不同的“虚拟页面”来展现应用，大致的资源关系如下：

从下往上看，应用一般有一个入口模块，比如app，这个入口模块根据url来动态决定异步加载某个页面（P₁-P₄），而每个页面并不是孤岛资源，它们还会依赖其他组件，组件与组件之间可能还有共享的基础库依赖。

基于这样的资源依赖树结构，webpack是怎么解决资源合并和按需加载的？感觉静态分析打包不能很好的处理按需和请求合并问题，要么每个chunk冗余合并，要么多个chunk串行加载

[wyntau]

借这里向大家请教一个问题. 我原本写在博客上的. 这里讨论 webpack 多一些, 所以在这里向大家请教.

我的原文地址 webpack 的 chunkId 是不是一个好的概念

webpack 的 chunkId 是不是一个好的概念

webpack 因为有各种各样的 loader, 可以让我们把所有的东西都使用相同的 require 写法进行加载, 同时还可以配合各种 compiler, 让我们从现在就可以享受到 ES6 给我们带来的便利, 所以 webpack 受到了大家的欢迎, 成为 2015 - 2016 特别受欢迎的打包及模块化方案.

但是在使用 webpack 的时候, 遇到了一个不小的问题, webpack 的 chunkId 对于永久缓存的支持.

假设我们有这样一个 SPA 页面场景, 有一个路由文件 route.js, 会在此文件中使用 webpack 的 code spliting 写法, 按需加载文件.

在 route.js 中分别对应三个页面(foo, bar, baz), 按需加载对应的入口文件. 在入口文件中, 会再分别加载各个子页面依赖的文件.

• foo.js
  • dep1.js
  • dep2.js
• bar.js
  • dep2.js
  • dep3.js
• baz.js
  • dep1.js
  • dep3.js

当我们使用 webpack 进行 build 后, webpack 会给每个文件分配一个 chunkId, 这个 chunkId 是随着 webpack 处理到的文件的数目而进行递增的. 一种结果是类似于下面这样的, 文件后面的括号中是生成的 chunkId 号

• foo.js (1)
  • dep1.js (4)
  • dep2.js (5)
• bar.js (2)
  • dep2.js (5)
  • dep3.js (6)
• baz.js (3)
  • dep1.js (4)
  • dep3.js (6)

如果我们需要在foo.js中增加一个依赖 dep4.js, 那么相应的 chunkId 会变成类似于下面这样

• foo.js (1)
  • dep1.js (4)
  • dep2.js (5)
  • dep4.js (6)
• bar.js (2)
  • dep2.js (5)
  • dep3.js (7)
• baz.js (3)
  • dep1.js (4)
  • dep3.js (7)

我们只增加(或删除)了一个文件, 却导致了多个文件的 chunkId 变化, 这样就导致多个文件的内容发生了变化. 那么当重新发布后, 其实有的页面的内容根本不需要变化, 但是仅仅是因为 chunkId 变化, 而导致需要重新下载这些文件, 使得没法使用浏览器已经缓存的文件.

如果你的页面有几十个, 每次添加或者删除一个文件后, 都会导致几乎所有的文件的浏览器缓存失效.

我们期望的结果是, 每当我们修改一个文件后, 只有依赖此文件的文件会更新, 而其它的文件不会发生变化. 当重新发布后, 只会去重新下载那些已经被更新的文件, 这样我们就可以做到类似于增量更新的效果.

但是 webpack 采用的 chunkId 的概念好像没办法避免这样的问题. 如果将 chunkId 换成依赖文件的路径, 是不是可以减少这种问题的发生呢?

---

在项目中把 webpack 换成了 FIS3, 解决了这个问题. 因为在FIS中, 依赖就是使用的文件路径, 所以文件位置不变, 依赖的id也是不变的.
依赖合并的问题, 我是把一些全局依赖使用 __inline 的方式合并到一个文件中. 其它的分散依赖则使用 require.async 进行按需加载

[lisaRao]

mark~~

[jpuncle]

Mark

[chemdemo]

@fouber

webpack可以通过CommonsChunkPlugin插件来对公共依赖模块进行提取：

{
    entry: {
        a: './js/pages/a.js',
        b: './js/pages/b.js',
        c: './js/pages/c.js',
        d: './js/pages/d.js'
    },
    ...
    plugins: [
        // 提取公共依赖模块，这种适合提取共享的基础库，如jquery、underscore等
        new CommonsChunkPlugin('lib', ['a', 'b', 'c', 'd'], 4),
        // 提取a、b、c中至少两个共同依赖的模块
        new CommonsChunkPlugin('common-abc', ['a', 'b', 'c'], 2),
        // 提取a、d共同依赖的模块
        new CommonsChunkPlugin('common-ad', ['a', 'd']);
    ]
}

更多可以参考multiple commons chunks

静态分析打包是事先生成chunk，如果需要消除模块冗余，只能自行配置来提取，所以webpack也是有局限性和学习成本。

对于按需加载，比如你提到的这种场景，p1-p4就当做chunk来加载了：

// app.js

switch(hash) {
    // index#p1
    case 'p1':
        require.ensure([], function() {
            require('p1');
        });
        break;

    // index#p2
    case 'p2':
        require.ensure([], function() {
            require('p2');
        });
        break;

    ...
    // 依次类推
}

打包完成之后，p1到p4会生成名为[hash].chunk.js的一系列文件。

[luqin]

{
    entry: {
        'common/a': "./a",
        'page/b': "./b"
    },
    output: {
        path: path.join(__dirname, "dist"),
        filename: "[name].entry.js"
    }
}

输出的文件：

/dist
   /common
      a.entry.js
   /page
      b.entry.js

我不知道你们还有啥需求

[yalishizhude]

看了两天的webpack，觉得还是配置太复杂了，不如gulp好用~

[levelio]

mark

[db-murphy]

mark

[chemdemo]

@oluul 你基本跟我想一块儿去了，我就是这个意思。

构建工具和加载工具分开，构建工具负责解析资源依赖并生成依赖表。
加载工具就可以多种多样了，ng合并是最简单原始的一种，另外前端同样需要实现一个加载框架，就是用于处理缓存和重复加载的问题，其实我期望的是形成统一的资源表标准和加载器标准，有浏览器统一来实现，这样才算完美。

参考这里的回复

[dingyiming]

• 看了又看，还得多看看，谢谢

[mc-zone]

@chemdemo 好久没来了，才看到你在上述（9月）的回复，你建议我可以试试scriptJS来异步加载所需模块。
问题是这样加载到的模块，是不具备webpack模块引用的功能的，它们不存在webpackJsonp队列中，不能互相引用，说白了只能适用全局的常规插件，但想走模块规范形式就不行了。有解决方案么

同问，在进行CMD模块迁移中卡在这里了。:dizzy_face:

[yangzj1992]

mark

[Heqingsong]

mark

[hum-57blocks]

mark

[wyntau]

@FrendEr 你把第一个 app.js 也放到 array 里面呢

[chemdemo]

@treri

纠正下，webpack生成的是moduleId不是chunkid。你说的这个的确是个问题，在很多群里我们都讨论过了，目前这可以说是webpack的一个bug，暂时无解。

我跟你的想法一样，也在考虑fis来取代webpack，因为fis团队发布了支持npm的模块fis3-hook-node_modules，不过我还没时间尝试，你可以研究下。

[hjzheng]

@treri 是的 但是 commitizen 这个东西也可以自己定制，也很方便 我们自己定制的 https://github.com/ShuyunXIANFESchool/shuyun-cz-conventional-changelog

[luqin]

先占位，学习学习

[FrendEr]

赞！持续关注！敢问作者大概啥时候会出下篇？

[bluetomlee]

占位，学习

[fouber]

@chemdemo

我应该是理解webpack的做法的，只是你可能没有注意到我的例子是一个怎样的陷阱：

webpack可以通过CommonsChunkPlugin插件来对公共依赖模块进行提取

单独看我例子中的a、b依赖c的情况，这个说法是正确的。

对于按需加载，比如你提到的这种场景，p1-p4就当做chunk来加载了

单独看我例子中的app加载p1-p4，这个说法也是正确的。

但是，把二者结合起来，就不是那么回事了。。。

因为p1-p4各自为一个chunk，其结果就是p1-p4不用处理，就是文件本身就行了；而ab抽取公共依赖c，也等价于三个文件不用处理，自然就是“c为ab的公共chunk”，在静态分析的模式下，这个例子的最优合并结果居然是不合并！

现实中这样的例子其实更多，而且会更复杂，静态分析面对大工程最终的结果往往是要么因为其局限性而根本配不出来合理的方案，要么因为配置太多维护成本过高而变成一个bundle的情况，没有真正的优化空间，那些“有公共依赖抽取插件从而进行优化”的假设基本形同虚设。

[chemdemo]

@fouber
这个例子很特殊啊，webpack资源合并的最优结果是不合并，但是webpack内部已经自动“标识”了资源之间的依赖关系（包括加hash戳）。所以这并不矛盾，生成的chunk的最小单元就是一个资源文件。

想象在某种理想情况下，静态资源构建的结果不是合并文件（资源内嵌除外），而是分析资源之间的依赖并且有工具去识别这种依赖关系，在资源下载的时候支持combine......

所以“资源表+资源加载框架”这个概念我算是理解通了，看来要去学习下FIS。

不过关于webpack require 的设计：

1.require就是一个标识符，至于资源如何加载（或依赖标记）的，看对应的loader怎么实现。
2.凡是通过require标识加载的资源，对于资源中使用了浏览器直接可识别的外部资源加载API，webpack都会预先使用loader加载，比如某个模板里边使用img src引用了图片，编译时图片最终也是交给image loader去加载的，css同理。

[VaJoy]

为方便同步、打包，都走的本地文件形式，在webpack里引用非本地文件只能通过externals来实现么，但这种情况下希望实现懒加载又不行了（require.ensure内还是必须使用的本地模块或提前下载好了的模块）。

像我司大部分移动端项目都会把公共模块（CMD模式）投放到分发的CDN上（服务器配置的资源过期时间很短也不建议修改之，webpack 的文件hash形式不太适用），客户端第一次则下载并存入localstorage，下次则直接从本地取，这种缓存模式走 webpack 是否有办法实现？

这样就忍痛舍弃了seajs的依赖就近模式（比如可以使用require.async在需要的时候才下载某模块），需要一口气先把全部需要的公共模块都下载下来（就是我第一段提及的问题）。但在旧项目我们先引入了seajs才下载模块，而在webpack 需要走externals配置（即在webpack打包后的bundle下载之前先下载），这时候是还没有模块加载器的，就悲剧了。。。

不知道对于我描述的问题是否有好的解决思路，我暂时也只想着留给后续的新项目用新的开发模式来走webpack，但这样新旧两种开发模式，开发和维护成本都有点高（无奈脸）

[chemdemo]

@VaJoy

参考下这个issue

webpack是一个模块打包器，不是文件加载器，它只能加载本地磁盘上的文件。对于你们的情况，CDN的公共lib可以采用scriptjs加载，因为本地还需要判断localstorage，所以需要先判断local再加载，代码类似：

if(localStorage.getItem('lib-content')) {
    // todo
} else {
    var $script = require("scriptjs");
    $script('http://cdn.yourdomain.com/lib/jquery.js', function() {
        // todo
    });
}

而这段代码就可以放到入口文件里使用webpack打包。

对于公共业务module，个人觉得还是在开发时存放到本地比较好，开发完可以发布到npm或者公司内部模块管理平台。

[lilJay-lin]

谁能跟我说说，issue能收藏吗，小白白路过。。

[chshouyu]

@lilJay-lin 你在这里回复了之后，以后有新的回复时你会收到通知的

[FrendEr]

大牛，有个问题请教。我正在使用webpack做构建，我有多个entry，这时output的目录能指定多个，达到一对一的效果吗？就是'/src/common/a.js' --> '/dist/common/a.bundle.js'，'/src/page/b.js' --> '/dist/page/a.bundle.js'。请问大牛这种现在webpack能实现吗？

[luqin]

可以的，参考官方文档吧

[chemdemo]

@FrendEr 这种好像做不到，filename项只支持字符串。

[chemdemo]

@io3 有例子吗 我没这样做过哎 一般无需关注webpack输出的结果。

[FrendEr]

@io3 对啊，有没有线上的例子或者教程呀？有点急，在线等哈！

[luqin]

{
    entry: {
        'common/a': "./a",
        'page/b': "./b"
    },
    output: {
        path: path.join(__dirname, "dist"),
        filename: "[name].entry.js"
    }
}

具体还可参考 http://webpack.github.io/docs/multiple-entry-points.html 页面底部的三种示例

[FrendEr]

@io3 这里最终打包的都是到了 /yourpath/dist/下面而已吧，都是同级的。我需要的是根据入口文件的路径来确定输出文件的路径哦

[luqin]

我发的code中，/就会自动生成文件夹目录。我项目都是这么用的

[chemdemo]

@io3 你的示例明显达不到他的需求啦 filename如果支持函数就可以

[luqin]

我这也是多个entry，每个entry自己指定目录，达不到他需求？

[FrendEr]

@io3 恩。多个entry是可以达到的，但是output不行。我是希望output可以为每个文件指定不同的目录

[chemdemo]

额 好吧 看出来了

[FrendEr]

@chemdemo @io3 好腻害！！谢谢两位！

[daifee]

你好，请原谅在这里问一个关于webpack的问题。

需求是“单页应用&按需加载”。实践过程中遇到了问题。下面是问题描述：

目录结构：

/app
  |-- components/
  |           |-- header.js
  |-- pages/
  |        |-- index.js
  |        |-- about.js
  |        |-- login.js
  |-- entry.js

描述：

• pages/index.js和pages/about.js都依赖components/header.js
• pages/login.js不依赖components/header.js
• entry.js是入口文件，根据URL按需加载pages/*.js

// 监听path路径，按需加载
window.addEventListener('popstate', function () {
  switch (path) {
    case '/':
      require.ensure(['./pages/index.js']);
      break;
    case '/about':
      require.ensure(['./pages/about.js']);
      break;
  }
});

结果：生成了两个按需加载的chunks，但两个chunks都包含了components/header.js。即存在两份。

期望结果：components/header.js作为一个独立的chunk。这样可以减少代码量（代价是多了请求数量）

webpack能实现我期望结果的需求吗？

[chemdemo]

@epooren

可以在打包的时候将components/header.js作为独立的入口：

{
    entry: {
        'components/header': 'components/header.js',
    }
}

在html里需要手动引用。

[FrendEr]

按照这个例子有个问题：

{
    entry: {
        a: './js/pages/a.js',
        b: './js/pages/b.js',
        c: './js/pages/c.js',
        d: './js/pages/d.js'
    },
    ...
    plugins: [
        // 提取公共依赖模块，这种适合提取共享的基础库，如jquery、underscore等
        new CommonsChunkPlugin('lib', ['a', 'b', 'c', 'd'], 4),
        // 提取a、b、c中至少两个共同依赖的模块
        new CommonsChunkPlugin('common-abc', ['a', 'b', 'c'], 2),
        // 提取a、d共同依赖的模块
        new CommonsChunkPlugin('common-ad', ['a', 'd']);
    ]
}

生成的lib.js和common-abc.js里面都定义了window["webpackJsonp"]，如下面的代码。他们会出现覆盖的情况。

var parentJsonpFunction = window["webpackJsonp"];
/******/    window["webpackJsonp"] = function webpackJsonpCallback(chunkIds, moreModules) {
         ...
         ...

请问怎样解决呢？

////////////////////////////////////////////////

找到问题了

 // 提取公共依赖模块，这种适合提取共享的基础库，如jquery、underscore等
 new CommonsChunkPlugin('lib', ['a', 'b', 'c', 'd'], 4),
 // 提取a、b、c中至少两个共同依赖的模块
 new CommonsChunkPlugin('common-abc', ['a', 'b', 'c', 'lib'], 2),

把lib加到common-abc的chunks数组里面就好了，但是在页面引用的时候一定得先引用common-abc.js，再引用lib.js。。。这样虽然可以用，但是有点违背依赖的直觉

[pronebel]

例子编译后，为啥编译运行之后，assets下a.html,b.html,c.html都缺少 webpackJsonp 这个的定义。看了下，只在common-bc的js文件下存在，但没有自动引用

[mostshow]

！

[gejiawen]

mark

[VaJoy]

@chemdemo 好久没来了，才看到你在上述（9月）的回复，你建议我可以试试scriptJS来异步加载所需模块。
问题是这样加载到的模块，是不具备webpack模块引用的功能的，它们不存在webpackJsonp队列中，不能互相引用，说白了只能适用全局的常规插件，但想走模块规范形式就不行了。有解决方案么

[geraldlrh]

mark

[oluul]

@chemdemo @fouber 下面这句话基本理解，但有些疑问。

想象在某种理想情况下，静态资源构建的结果不是合并文件（资源内嵌除外），而是分析资源之间的依赖并且有工具去识别这种依赖关系，在资源下载的时候支持combine......

如下几个问题
引用1：分析资源之间的依赖并且...

• 问1： 是否可以通过webpack 生成的stats来进行分析？

引用2：且有工具去识别这种依赖关系，在资源下载的时候支持combine

• 问2：可否简单理解这个功能提供类似反响代理、nginx_concat_module的功能(或者是纯前端的实现，应该叫做加载器)，如果是实际环境下的话可能需要支持云处理(或者生成一大堆可能出现的情况)
• 问3：以上引用里面会存在一个问题，此方案并未解决“重复下载公共文件”。（目前这种方案不可行的地方在两处 1.http下发多个文件， 2.这多个文件的缓存。还有一种方案是前端需要有一个加载器来合并这些请求，且拿到combind的数据后再拆分存储在browser中，按现有方案，只能用localstorage类的）

---

update:看完 fouber的文章后清晰多了，欢迎回复交流

[caihg]

请教有关webpack的两个问题：

1. 对于在模板中用 img src="*" 引入的图片，怎么加md5戳并替换新的路径；
2. 怎么将不同页面的图片加md5戳后输出到对应的目录下
   例如：page1.html用到的图片输出到page1目录下，page2.html用到的图片输出到page2目录下

webpack.config.js 相关配置如下：
module: {
  loaders: [
    {
      test: /.(jpe?g|png|gif)$/,
      loader: 'url?limit=8192&name=images/[name]-[hash:8].[ext]'
    }
  ]
},
plugins: [
  new HtmlWebpackPlugin({
    template: 'page1/page1.html',
    filename: 'page1/index.html',
    inject: 'body',
    chunks: ['libs', 'page1/page1-entry']
  }),
  new HtmlWebpackPlugin({
    template: 'page2/page2.html',
    filename: 'page2/default.html',
    inject: 'body',
    chunks: ['libs', 'page2/page2-entry']
   })
]

[lawrence-peng]

路过，好精彩

[chemdemo]

@caihg
第一个问题，html中引用的图片会自动修改路径的和加hash戳，只要你配置了图片loader
第二个问题，url-loader提供了资源路径作为占位符，即[path]，可以根据path项配置输出路径

[nerona]

Mark

[zhrren]

路过，好精彩

[yifei337]

• webapp/ # webapp根目录
  • src/ # 开发目录
    • css/ # css资源目录
    • img/ # webapp图片资源目录
    • login/ # 登陆页图品目录
      • a.png
      • b.png
    • home/ # 首页图片目录
    • c.png
  • assets/ # 编译输出目录，即发布目录
    • js/ # 编译输出的js目录
    • img/ # webapp图片资源目录
    • login/ # 登陆页图品目录
      • a.png
      • b.png
    • home/ # 首页图片目录
    • c.png

请问输出这样的图片目录， webpack 中怎么配置

[coderlaoma]

路过，再回头看看

[chemdemo]

webpack和gulp不是同一类型的东西，前者是打包工具后者可以看成是一个任务调度器，拿在一起比较不合适

[henryzp]

mark

[cycold]

mark

[Thestars]

mark

[huboshu0819]

mark

[maxfine]

mark

[aklivecai]

mark

[hszy00232]

mark

[shallinta]

mark

[liupeng110112]

mark 文章和评论都值得好好看下

[chemdemo]

@mc-zone
你们说的是AMD吧？amd的加载可以参考这里：
https://webpack.github.io/docs/amd.html
还有个例子：
https://github.com/webpack/webpack/tree/master/examples/mixed

[chemdemo]

@VaJoy
webpack只会加载在线的模块（在本地没有已经下载完成的情况下），最多是走HTTP缓存，需要存储到local里的情况需要自己去做判断。

[chemdemo]

@caihg
第一个问题，可以在HtmlWebpackPlugin前使用html-loader，参考webpack-config.js#L68，webpack-seed这个项目已经fix了你说这个问题。

第二个问题，参考下file-loader的path选项，在输出结果里配置不同的路径。

[chemdemo]

@yifei337 参考上一条comment

[studzw]

@VaJoy 你说的这个问题，最近让我大伤脑筋。生无可恋脸
不知道过了这么久，你有没有好的解决方案！

[hugzh]

好东西

[FrendEr]

@chemdemo 你好，请教个问题。

一个模块是不是不能作为entry两次？如下

entry: {
  index: 'app.js',
  'index-polyfill': ['app.js', 'polyfill.js']
}

打包报错：

Module not found: Error: a dependency to an entry point is not allowed

不知道这个问题有没有解决方案呢？

[FrendEr]

@treri 这样居然OK了！！！感谢！

[bairedzhang]

真心赞 mark下 慢慢看

[Pillar-Zhang]

mark 准备好好学webpack 不知道现在这个工具就目前被项目采纳的程度怎么样？ 知道的前辈 说说 大概都有哪些坑 我等后生 可以少跳点

[juzipi]

慢慢看

[myqianlan]

@treri
https://github.com/diurnalist/chunk-manifest-webpack-plugin

[wyntau]

@myqianlan 谢谢. 已经把构建工具切换到FIS3了. 整体用下来感觉比webpack更简单.

[chemdemo]

@treri fis3对npm的支持怎么样了

[wyntau]

@chemdemo 目前还没用hook npm.😰

[chemdemo]

好吧 不考虑npm的话用哪个无所谓啦

[yalishizhude]

webstorm 不算为前端打造的IDE？
那么强的调试能力和智能化提示~

[yalishizhude]

《善用软件-提高编程效率》http://dwz.cn/3J1gle

另外visual studio code 听说也不错~

[henryzp]

@treri ,想了解一下，你们lint这一块，fis是怎么处理的？

我用fis的相关lint npm包，可以使用

fis3 release -l

但是有两个问题，

• 当文件写的有问题，确实会有提示，但是它也把文件给输出去了
• fis 有没有纯命令来检验代码的

毕竟像grunt/gulp，只要配置一个指令就OK了。。

之前有在群里面聊过，有些人提到用webstorm来做代码校验，但我觉得工具上能不能再加一个保障，毕竟不能强迫别人一定要用webstorm。

[wyntau]

@henryzp
我没有使用fis来进行lint检查, 我是单独用的eslint来执行lint的.
只不过是选了不同的检查时机. 我是在 git commit的时候进行强制检查, 检查不通过, 直接不允许commit.
这样, 团队中的人都一定会通过lint了

可以看我写的这篇
http://isay.me/2016/05/use-eslint-force-code-style-check.html

[henryzp]

@treri

团队中有用git，也有用svn，git的团队可以保证用你的写法，其实也有一个pre-commit，这个玩意来保证。。但是svn的前端团队，似乎没有好的办法了？

[hjzheng]

@treri 和 @henryzp 推荐使用 https://github.com/typicode/husky ， 目前我们团队使用这个， 另外在推荐一个 commitizen 设置提交模板很方便，自己定制一下。参见PPT

[wyntau]

@henryzp

我基本上没用过svn, 这块可能知道的不多.

这样的话, 只好研究一下配置fis的lint了 😰

或者大家都自觉的自己检查一下, 只不过这个有点不现实, 因为有的人根本不知道什么是lint...

当然最好还是促进大家转到git上面去了 😁

[wyntau]

@hjzheng 我目前也在使用了commitizen, 只不过只是使用了commitizen 的 cz-conventional-changelog 规范, 没有使用这个工具进行提交.
项目中配置了commitizen命令, 只不过是我自己为了写commit log时省事加的. 团队其他人只要遵守commit log规则就好了.

这是我的另一个 git hook, 和上面的 pre-commit进行lint的搭配使用. 检查失败了, 直接引导去看阮一峰写的博文去了😄

你说的这个工具我当时看了. 感觉自己配置的更灵活吧 😁

#!/bin/bash

msg=$(head -n 1 $1)

if echo $msg | grep -iqE "^Merge "; then
  exit 0
fi;

if echo $msg | grep -iqE "^Revert "; then
  exit 0
fi;

if echo $msg | grep -iqE "^(feat|fix|docs|style|refactor|perf|test|chore)(\([^()]{1,}\)){0,1}: .{1,}"; then
  exit 0
fi;

echo
echo -e "\033[41mINVALID COMMIT MSG:\033[0m Does not match \"<type>(<scope>): <subject>\" !"
echo
cat <<EOF
Available types and what it mean are list here

  feat:     A new feature
  fix:      A bug fix
  docs:     Documentation only changes
  style:    Changes that do not affect the meaning of the code
            (white-space, formatting, missing semi-colons, etc)
  refactor: A code change that neither fixes a bug or adds a feature
  perf:     A code change that improves performance
  test:     Adding missing tests
  chore:    Changes to the build process or auxiliary tools
            and libraries such as documentation generation

EOF
echo -e "Please read http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html"
echo

exit 1

[henryzp]

@hjzheng ,你上面发的git链接，应该是类似于我之前写的一篇文章：

pre-commit

[bytemofan]

有的公司的cdn域名是分开的，就比如：
js的cdn域名：js.xxcdn.com.cn
css的cdn域名是：css.xxcdn.com.cn
images的cdn域名是:img.xxcdn.com.cn

在这种情况下，webpack的一个publicPath配置貌似不能区分，所以在用html-webpack-plugin插件注入模板的时候，所有注入的文件的路径名就只有一个cdn域名，即publicPath里边配置的那个cdn域名。

...
output:{
       path:APP_PATH,
       filename:'[name].js',
       publicPath:'http://xx.xxcdn.com.cn/'
},
...

plugins:[
    new ExtractTextPlugin("[name].css"),
    new HtmlWebpackPlugin({
        filename:"test.html",
        template:path.resolve(APP_PATH,"./html/test.html"),
        inject:"body"
    })
],
...

这么生成的页面就会是这种：

<!DOCTYPE html>
<html lang="en">

<head>
    ...
    <title>这是一个测试的页面</title>  
    <link href="http://xx.xxcdn.com.cn/test.css" rel="stylesheet">
</head>
<body>
    <p>
        Hello word!
    </p>
    <script type="text/javascript" src="http://xx.xxcdn.com.cn/test.js"></script></body>
</html>

但我其实想要的是css被注入为:

<link href="http://css.xxcdn.com.cn/test.css" rel="stylesheet">

js被注入为:

<script type="text/javascript" src="http://xx.xxcdn.com.cn/test.js"></script></body>

不知道webpack能不能做到这种呢？还请大神们解解惑，我只是一个初入坑的小白......QAQ

目前我的做法是不用插件来注入了，而是直接在模板页面上写地址。但是这样一点都不智能呢.......

[chemdemo]

@Mmzer 是的 publicPath不支持函数，这个是个缺陷
难不成国外没这种分cdn域名的需求哈哈哈

[wyntau]

@Mmzer 如果有这种需求, 建议去看下 FIS3. 这样的需求, 使用 FIS3 可以算是 so easy

[zhangbg]

学习了

[vegawong]

问题: 如何处理服务端模板的img中的src指向?

我看楼上已经有提过类似的, 也有回答, 不过只限于纯前端模板解析, 类似用loader去过一遍html之类的, 并不能满足需求, 我这里处理的是服务端的模板, 而家不一定是html, 有可能是ejs, jade之类, 这种情况下img的src好尴尬啊...

[chemdemo]

如果是html或者类html模板（ejs、jade），应该有相应的loader可以做。
不过其他语言的模板如smarty、jsp之类的目前好像没法这么做。

[geraldlrh]

@treri @chemdemo 关于chunk id的问题，使用manifest和NamedModulesPlugin，是可以解决的。
参考 webpack/webpack#1315 和 https://github.com/kevinrenskers/chunkhash-problem

[Meqn]

mark