关于webpack中tree-sharking优化策略与sideEffect

再写项目时难免会出现部分代码写了却没有使用,代码量小没什么影响,但是当开发量多的时候,或是大量遗传代码叠加时,打包体积就会明显比较大。在webpack中可以使用tree-sharking进行代码优化。有两种代码优化策略tree-sharking(useExports)与sideEffect ,可以先大致了解一下什么时副作用

副作用

副作用(effect 或者 side effect)指在导入时会执行特殊行为的代码,而不是仅仅暴露一个或多个导出内容。polyfill 就是一个例子,尽管其通常不提供导出,但是会影响全局作用域,因此 polyfill 将被视为一个副作用。

sideEffect与useExports不同应对策略

使用webpack就会直接sharing掉这些‘死代码’,如import '../../.css',了解过react,应该知道其高阶组件部分就是负效应下面会讲到,像

import {button} from ' xx'
...
...
...
withAppProvider()(Button);

sideEffect应对策略

根据官方文档,对于有负效应的code,sideEffect可以添加以下代码直接跳过相关模块的检查,避免被无意删除,因为他作用在模块层面,所以`sideEffects 更为有效 是因为它允许跳过整个模块/文件和整个文件子树。

{
  "name": "your-project",
  "sideEffects": ["./src/some-side-effectful-file.js", "*.css"]
}

最后,还可以在 [module.rules 配置选项]中设置 "sideEffects"

tree-sharing应对策略

提示:所有导入文件都会受到 tree shaking 的影响。这意味着,如果在项目中使用类似 css-loader 的东西并导入了一个 CSS 文件,则需要将其添加到副作用列表中表示其存在副作用,以免在生产模式中无意中将它删除:
usedExports 依赖的 terser 就尝试去解决这些问题,但在许多情况下它仍然不确定函数的调用是否有副作用。但这并不意味着 terser 会由于无法解决这些问题而运作得不好。根本原因在于像 JavaScript 这类动态语言中很难可靠确定这一点。
主要使用方法,在副作用代码前面加入/*#__PURE__*/提示

var Button$1 = /*#__PURE__*/ withAppProvider()(Button);

光是这样可以删除部分副作用代码,但是引用的内容可能还会有副作用,这需要在我们需要在 package.json 中添加 ["sideEffects"]属性。

参考文档:https://www.webpackjs.com/guides/tree-shaking/#mark-the-file-as-side-effect-free

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容