webpack 应用编译优化之路 about ddfe-blog HOT 23 OPEN

发现一处笔误：import { Dialog } form 'cube-ui'。"from"拼错了~

from ddfe-blog.

@linrui1994 我的理解是以前的项目是使用webpack 1开发的，而webpack 1中加载包时会对应到pakage.json的"main"字段去解析。参考http://devdocs.io/webpack~1/resolving

在webpack 2+，加载包时会优先到对应的”module"字段去解析。参考https://doc.webpack-china.org/configuration/resolve/#resolve-mainfields

因此为了兼容以前使用webpack 1的老项目，会在npm包的package.json（比如cube-ui组件包）中提供两个入口。

from ddfe-blog.

每个包需要管理自己的后编译依赖，相当于建立一套后编译的生态，目前来看适合自己团队内部去维护这套生态。

from ddfe-blog.

666，感谢分享干货，已推荐到 SegmentFault 头条 (๑•̀ㅂ•́)و✧
链接如下：https://segmentfault.com/p/1210000011520990

from ddfe-blog.

感谢分享

from ddfe-blog.

感谢分享。

from ddfe-blog.

感谢分享。

from ddfe-blog.

感谢分享，先收藏吧

from ddfe-blog.

编译优化的话可以考虑 DLL，可以缩短编译时间。

from ddfe-blog.

入口之争这一部分没读懂，main和module字段的区别，比如require('a')读的是main字段，import 'a'读的是module字段吗？ 谁能告诉我，我哪里错了?

from ddfe-blog.

@tank0317 原来是这样，这样就清楚了，我原来的理解是错的，还是文档没看彻底

from ddfe-blog.

灰常好，讲解的很赞～～

from ddfe-blog.

这些方案在webpack3上可行吗？同样的代码，之前试过用webpack2和webpack3打包，打包后的app.js和vendor.js，3比2的小很多了

from ddfe-blog.

3 支持的，4的话目前还没测验，很快会考虑4的一些兼容

from ddfe-blog.

想请教大神一个问题：

在后编译这块，按照您的解释，如果项目依赖 A，就需要在项目的 package.json 中写入 compileDependencies: ["A"]，这个OK。

但如果模块 A 还依赖 C 和 D，还要求在 A 里面写 compileDependency，这个要求是不是有些勉强？

例如我依赖了 lodash，我如何控制 lodash 的 package.json ？还是说您这套做法只适用于自己发布的 npm 包？

谢谢大神

from ddfe-blog.

目前使用babel 6和webpack 4测试后，发现无法处理ES6的class经babel编译后会出现IIFE情况（即副作用函数问题）

使用该插件，tree shaking依然无法去掉没有调用到的class声明状况

from ddfe-blog.

我记得好像在 vue-cli 3 中，对于依赖包默认是不编译直接打包。所以后编译实际上在 vue-cli 3 中好像已经没什么用了。

详见

• https://vue-loader.vuejs.org/zh/guide/pre-processors.html#%E6%8E%92%E9%99%A4-node-modules
• https://cli.vuejs.org/zh/config/#transpiledependencies

from ddfe-blog.

@zimtsui 默认nodemodules 都是不编译的，所以需要编译，这才是后编译。

后编译插件现在已经1.0版本了。

除了兼容上述的手工指定 compileDependencies 外，包自身声明的 postCompile 字段的优先级最高，甚至还可以指定文件目录，这部分借助于 minimatch 做的匹配。

如果从广度来看，如果有很多依赖包，借助于工具，以及自身声明就可以满足需求了；且这种方案不仅可以应用在 vue 生态中，React也一样。

from ddfe-blog.

@dolymood 谢谢指出，我之前理解错了后编译的目的。

from ddfe-blog.

@dolymood 有个疑问，为什么不直接去掉
include: [path.resolve(__dirname, 'src')]
让webpack对所有引用的包都做处理。这样就可以一劳永逸的解决源码编译的问题了啊，唯一的坏处不就是增加了点打包时间吗，这个一般感觉不到吧。
我是发现preact-cli生成的项目就是可以天然支持源码后编译的，把它的webpack配置打印出来看了下，就是没有include: [path.resolve(__dirname, 'src')]。

from ddfe-blog.

比我们做的深入，赞一个

from ddfe-blog.

有点意思，最近遇到了同样的问题。

from ddfe-blog.

编译优化，推荐使用DllPlugin， 提升构建的速度。

from ddfe-blog.