Webpack 4从具有副作用的程序包中期望什么:false

问题描述

Webpack 4添加了一个新功能:现在，它捆绑的模块的package.json中支持sideEffects标志.

Webpack 4 has added a new feature: it now supports a sideEffects flag in the package.json of the modules it is bundling.

来自 Webpack 4:今天发布

来自 Webpack文档

尽管第二个链接显示了使用该标志的结果，但并未明确解释什么构成了副作用. ES6包括了此处概述的模块副作用的概念，但是如何这与Webpack认为的副作用有关吗?

Whilst the second link shows the results of using the flag, it doesn't clearly explain what constitutes a side-effect. ES6 includes the concept of side-effects for modules as outlined here, but how does this relate to what Webpack considers side-effects.

在sideEffects标志的上下文中，模块需要避免使用无问题的sideEffects:false的方法，或者相反，模块需要做什么才能使用sideEffects:false没有问题的操作.

In the context of the sideEffects flag, what does a module need to avoid to use sideEffects:false without issues, or conversly, what does a module need to do in order to use sideEffects:false without issues.

为了完整起见，尽管下面有@SeanLarkin的明确回答，但我还是想澄清以下内容:

For completeness, despite @SeanLarkin's solid answer below, I would love to get clarification on the following:

1. 显然，副作用是fp中的特殊现象，包括日志记录(控制台或其他地方)和引发错误.在这种情况下，我假设这些完全可以接受吗?

1. Obviously side-effects means something particular in fp and would include logging (console or elsewhere) and the throwing of errors. I'm assuming in this context these are perfectly acceptable?

模块可以包含循环引用并且仍使用sideEffects: false吗?

Can a module contain circular references and still use sideEffects: false?

除了尝试跟踪由于误用导致的错误之外，还有什么方法可以验证或者模块能够验证该模块是否可以sideEffects: false?

Is there any way to verify or that a module is able to verify that a module can sideEffects: false beyond trying to track down errors caused by its misuse?

是否有其他因素会阻止模块使用sideEffects: false?

Are there any other factors that would prevent a module from being able to use sideEffects: false?

推荐答案

来自Webpack团队的Sean！我会尽力代替仍在处理中的文档，在这里回答您的问题！

Sean from the webpack Team! I'll do my best in lieu of our documentation still in progress to answer your question here!

根据ECMA模块规范(我不会尝试查找链接，因此您必须在这里信任我，因为它被埋藏了)，

According to the ECMA Module Spec (I'm not going to try and find the link so you'll have to trust me here because its buried),

每当模块重新导出所有出口(无论使用或未使用)时，都需要对它们进行评估和执行，以防其中一个出口与另一个出口产生副作用.

whenever a module re-exports all exports, (regardless if used or unused) they need to be evaluated and executed in case one of those exports created a side-effect with another.

例如，我用照片创建了一个小场景，以更好地形象化此情况:

For example I've created a small scenario with a photo to better visualize the case:

在这张照片中，我们看到了三个模块导入到一个文件中.然后，从该模块重新导出导入的模块:

In this photo we see three modules imported into a single file. The imported modules are then re-exported from that module:

您可以在此处看到任何重新导出都不会相互影响，因此(如果给了webpack一个信号)，我们甚至可以忽略或使用导出b和c(大小和构建)时间绩效带来的好处).

You can see here that none of the re-exports are effected by eachother, therefore (if webpack was given a signal), we could omit exports b and c from even being traced or used (size and build time performance benefits).

但是，在这种情况下，我们看到导出c受本地状态更改影响"，因为它被重新分配给b和a的总和.因此，(这就是规范要求这样做的原因)，我们需要将b和a以及其任何依赖项都包括在包中.

However in this case, we see that exports c is "effected" by local state changes because it is reassigned to the summation of b and a. Therefore, (which is why the spec calls for this), we would need to include both b and a and any of its dependencies into the bundle.

我们选择"sideEffects:false"作为节省编译时间和构建大小的一种方式，因为这使我们可以立即(显式)修剪开发人员/库作者知道没有副作用的导出(以牺牲package.json中的属性，或2-3行以上的配置).

We chose "sideEffects: false" as a way to save on both compile time and build size because this allows us to instantly prune (explicitly) exports that developers/library authors know are side-effect free (at the expense of a property in a package.json, or 2-3 more lines of config).

尽管从技术上讲该示例非常原始，但是当您开始处理将一组模块重新导出到更高级别以获得开发人员体验(Three.js，Angular，lodash-es等)的Frameworks或Libraries时，则可以提高性能当您以这种方式标记它们时(如果它们是sideEffect free模块导出)，则非常重要.

Although technically this example is very primitive, when you start dealing with Frameworks or Libraries that reexport a bunch of modules up to a higher level for Developer Experience (Three.js, Angular, lodash-es, etc), then performance gains are significant when (if they are sideEffect free module exports) you flag them in this manner.

其他说明:

1. 显然，副作用是指fp中的某些特殊现象，包括日志记录(控制台或其他地方)和引发错误.在这种情况下，我假设这些完全可以接受吗?

在尝试解决的情况下，是的.只要针对模块导出创建的效果不会受到其他因素的影响，这将导致修剪不可接受.

In the case that this is trying to solve, yes. As long as effects created against module exports aren't effected by others that would cause pruning to not be acceptable.

1. 一个模块可以包含循环引用并且仍然使用sideEffects: false?

1. Can a module contain circular references and still use sideEffects: false?

理论上应该如此.

1. 除了试图追踪由误用引起的错误之外，还有什么方法可以验证或者模块能够使用sideEffects: false?

1. Is there any way to verify or that a module is able to use sideEffects: false beyond trying to track down errors caused by its misuse?

我不知道，但这将是一个很好的工具.

Not that I know of, however this would be a great tool.

1. 还有其他因素会阻止模块使用sideEffects: false吗?

1. Are there any other factors that would prevent a module from being able to use sideEffects: false?

如果该属性不在package.json中或在module.rules中定义，或者未设置mode: production(这将利用优化).

If the property is not in package.json or defined in module.rules, or mode: production is not set (which leverages the optimization).

这篇关于Webpack 4从具有副作用的程序包中期望什么:false的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！