【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

不要再依赖 CommonJS 了

  • 2020-05-20
  • 本文字数:3491 字

    阅读完需:约 11 分钟

不要再依赖CommonJS了

在这篇文章中,我们将研究什么是 CommonJS,以及为什么它会让你的 JavaScript 包大小过分膨胀。为了确保打包器(bundler)能成功优化你的应用程序大小,请避免依赖 CommonJS 模块,并在整个应用程序中使用 ES2015 模块语法。


本文最初发布于web.dev网站,经原作者 Minko Gechev 授权由 InfoQ 中文站翻译并分享。

什么是 CommonJS?

CommonJS 是 2009 年的标准,为 JavaScript 模块建立了约定。它最初打算在 Web 浏览器之外的场景中使用,主要用于服务端应用程序。


使用 CommonJS,你可以定义模块,从中导出功能,并将它们导入其他模块中。例如,下面的代码片段定义了一个模块,其导出五个函数:add,subtract,multiply,divide 和 max:


// utils.jsconst { maxBy } = require('lodash-es');const fns = {  add: (a, b) => a + b,  subtract: (a, b) => a - b,  multiply: (a, b) => a * b,  divide: (a, b) => a / b,  max: arr => maxBy(arr)};Object.keys(fns).forEach(fnName => module.exports[fnName] = fns[fnName]);
复制代码


稍后,另一个模块可以导入和使用这些函数:


// index.jsconst { add } = require(‘./utils');console.log(add(1, 2));
复制代码


使用 node 调用 index.js 将在控制台中输出数字 3。


由于 2010 年代初期浏览器中缺乏标准化的模块系统,CommonJS 也成为了 JavaScript 客户端库的流行模块格式。

CommonJS 如何影响最终的打包大小?

服务端 JavaScript 应用程序的大小并不像浏览器中那样重要,所以 CommonJS 并没有在设计时考虑到包大小的控制。与此同时,有分析表明 JavaScript 的包体积仍然是拖慢浏览器应用的主要因素之一。


JavaScript 打包器和压缩器(minifier),例如 webpack 和 terser,会执行多种优化措施以减小应用程序的大小。它们在构建时分析你的应用程序,尝试尽可能删掉那些没用到的源代码。


例如,在上面的代码片段中,你的最终打包应该只包括 add 函数,因为这是你从 utils.js 中导入到 index.js 中的唯一符号。


我们使用以下 webpack 配置来构建这个应用:


const path = require('path');module.exports = {  entry: 'index.js',  output: {    filename: 'out.js',    path: path.resolve(__dirname, 'dist'),  },  mode: 'production',};
复制代码


在这里,我们指定了要使用生产模式优化并将 index.js 用作入口点。调用 webpack 之后,如果我们查看输出大小,将看到下面这样的内容:


$ cd dist && ls -lah625K Apr 13 13:04 out.js
复制代码


请注意,这个包的大小为 625KB。看一下输出,我们将找到来自 utils.js 的所有函数,外加来自 lodash 的很多模块。尽管我们在 index.js 中不使用 lodash,但它也被加进了输出,这给我们的生产资产增加了很多额外负担。


现在我们将模块格式更改为 ECMAScript 2015,然后重试。这次,utils.js 将变成如下所示:


export const add = (a, b) => a + b;export const subtract = (a, b) => a - b;export const multiply = (a, b) => a * b;export const divide = (a, b) => a / b;import { maxBy } from 'lodash-es';export const max = arr => maxBy(arr);
复制代码


并且 index.js 将使用 ES2015 模块语法从 utils.js 导入:


import { add } from './utils';console.log(add(1, 2));
复制代码


使用相同的 webpack 配置,我们可以构建应用程序并打开输出文件。现在大小只有 40 字节,输出如下:


(()=>{"use strict";console.log(1+2)})();
复制代码


请注意,最后的打包中并没有包含 utils.js 中我们没有用到的任何函数,而且也没有 lodash 的痕迹!更进一步,terser(webpack 使用的 JavaScript 压缩器)在 console.log 中内联了 add 函数。


你可能会问一个问题,为什么使用 CommonJS 会导致输出包大了接近 16,000 倍?当然,上面这个应用只是一个简单的示例,实际应用中的体积差异可能没那么大,但 CommonJS 也很有可能给你的生产构建增添了很大的负担。


一般情况下,CommonJS 模块难以优化,因为它们比 ES 模块动态得多。为确保打包器和压缩器可以成功优化应用程序,请避免依赖 CommonJS 模块,并在整个应用程序中使用 ES2015 模块语法。


请注意,即使你在 index.js 中使用了 ES2015,但如果你使用的模块是 CommonJS,应用程序的打包大小也会受到影响。

为什么 CommonJS 会让应用程序体积更大?

为了回答这个问题,我们将研究 webpack 中 ModuleConcatenationPlugin 的行为,然后讨论静态可分析性。这个插件将所有模块合并为一个闭包,并能让你的代码在浏览器中执行得更快。我们来看一个例子:


// utils.jsexport const add = (a, b) => a + b;export const subtract = (a, b) => a - b;
复制代码


// index.jsimport { add } from ‘./utils';const subtract = (a, b) => a - b;console.log(add(1, 2));
复制代码


如上所示,我们有一个 ES2015 模块,然后将其导入 index.js 中。我们还定义了一个 subtract 函数。我们可以使用与上面相同的 webpack 配置来构建项目,但是这次我们将禁用最小化:


const path = require('path');module.exports = {  entry: 'index.js',  output: {    filename: 'out.js',    path: path.resolve(__dirname, 'dist'),  },  optimization: {    minimize: false  },  mode: 'production',};
复制代码


看一下生成的输出:


/******/ (() => { // webpackBootstrap/******/   "use strict";// CONCATENATED MODULE: ./utils.js**const add = (a, b) => a + b;const subtract = (a, b) => a - b;// CONCATENATED MODULE: ./index.js**const index_subtract = (a, b) => a - b;**console.log(add(1, 2));**/******/ })();
复制代码


在上面的输出中,所有函数都在同一个命名空间内。为了防止冲突,webpack 将 index.js 中的 subtract 函数重命名为 index_subtract。


如果让一个压缩器处理上面的源代码,它将:


  • 删除未使用的 subtract 和 index_subtract 函数

  • 删除所有注释和多余的空格

  • 在 console.log 调用中内联 add 函数的主体


开发人员通常将这种移除未使用的导入的操作称为摇树优化(tree-shaking)。因为 webpack 能够静态地(在构建时)了解我们从 utils.js 导入及导出的符号,所以它才能实现摇树优化。


ES 模块默认启用此行为,因为与 CommonJS 相比,它们更容易进行静态分析


我们来看完全相同的示例,但是这次将 utils.js 更改为使用 CommonJS 模块:


// utils.jsconst { maxBy } = require('lodash-es');const fns = {  add: (a, b) => a + b,  subtract: (a, b) => a - b,  multiply: (a, b) => a * b,  divide: (a, b) => a / b,  max: arr => maxBy(arr)};Object.keys(fns).forEach(fnName => module.exports[fnName] = fns[fnName]);
复制代码


这个小小的更新会显著影响输出结果。受限于文章篇幅,这里我只分享其中的一小部分:


...(() => {"use strict";/* harmony import */ var _utils__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(288);const subtract = (a, b) => a - b;console.log((0,_utils__WEBPACK_IMPORTED_MODULE_0__/* .add */ .IH)(1, 2));})();
复制代码


请注意,最终的打包包含一些 webpack“运行时”:也就是注入的代码,负责从打包的模块中导入/导出功能。这次,我们不是将 utils.js 和 index.js 中的所有符号放在同一个命名空间下,而是在运行时动态请求使用__webpack_require__的 add 函数。


这是必需的,因为使用 CommonJS,我们可以从任意表达式中获取导出名称。例如,下面的代码是绝对有效的构造:


module.exports[localStorage.getItem(Math.random())] = () => { … };
复制代码


打包器无法在构建时知道导出的符号是什么名称,因为这里需要的信息在用户浏览器的上下文中,而且仅在运行时可用。


这样压缩器无法从 index.js 的依赖项中了解它到底使用了哪些内容,因此无法将无用代码优化。我们还能观察到第三方模块也有完全相同的行为。如果我们从 node_modules 导入 CommonJS 模块,你的构建工具链将无法正确优化它。

基于 CommonJS 实现摇树优化

由于 CommonJS 模块是动态定义的,因此它们分析起来要困难得多。例如,与 CommonJS 相比,ES 模块中的导入位置始终是一个字面量(前者则是一个表达式)。


在某些情况下,如果你使用的库遵循有关 CommonJS 用法的特别约定,则可以在构建时使用这个第三方webpack插件删除未使用的导出。但尽管这个插件增加了对摇树优化的支持,但并未涵盖依赖项使用 CommonJS 的所有可能方式。这意味着你无法获得与 ES 模块相同的保障。此外,除了默认的 webpack 行为外,它还会在构建过程中增加额外的成本。

结论

总之,再次强调,为了确保打包器可以成功优化你的应用程序,请避免依赖 CommonJS 模块,并在整个应用程序中使用 ES2015 模块语法。


原文链接:


https://web.dev/commonjs-larger-bundles/


2020-05-20 08:007580

评论 3 条评论

发布
用户头像
那就不要用webpack啊
2020-05-20 14:28
回复
用户头像
好文章
2020-05-20 13:01
回复
用户头像
infoq 真是个宝藏!
2020-05-20 09:42
回复
没有更多了
发现更多内容

书单 | 5月畅销新书情报,你最Pick哪一本?

博文视点Broadview

LeaRun .Net Core/Java工作流引擎,分离式前端,升级Vue

雯雯写代码

Vue 工作流引擎

架构实战营模块五作业

竹林七贤

🏆未来可期,WebRTC成为实时通讯方案的行业标准

洛神灬殇

音视频 WebRTC 实时通信 6月日更

Rust从0到1-泛型-trait

rust 泛型 Trait generic

《面试官:谈谈你对索引的认知》系列之B+树

架构精进之路

MySQL 索引结构 6月日更

基于开源Tars的动态负载均衡实践

vivo互联网技术

负载均衡 TARS

为什么说混合云是新基建的流行架构?

博文视点Broadview

总结笔记 Datawhale-23期数据挖掘-心跳信号分类预测

万里无云万里天

数据挖掘 6月日更 Datawhale

火爆全网的迁移学习简明手册全面更新,重磅出版上市!

博文视点Broadview

一封MySQL之父Monty的回信,开启彭立勋的数据库之路

华为云开发者联盟

MySQL 数据库 opengauss GaussDB 华为云数据库

毕业设计So Easy:珠穆朗玛FM音频电台APP

不脱发的程序猿

android 软件开发 APP开发 毕业设计 移动应用开发

国内首篇云厂商 Serverless 论文入选全球顶会:突发流量下,如何加速容器启动?

Serverless Devs

Serverless 容器 云原生

我把 Spring Boot 项目从 18.18M 瘦身到 0.18M,部署起来真省事!

xcbeyond

微服务 springboot 6月日更

网络攻防学习笔记 Day33

穿过生命散发芬芳

网络攻防 6月日更

chia奇亚挖矿系统开发案例介绍丨chia奇亚挖矿源码功能

系统开发咨询1357O98O718

图表示学习+图神经网络:破解AI黑盒,揭示万物奥秘的钥匙!

博文视点Broadview

自适应微服务治理背后的算法

万俊峰Kevin

微服务 自适应 服务治理 Go 语言

anyRTC SDK 5月迭代:优化自定义加密功能,让通信更安全

anyRTC开发者

音视频 WebRTC sdk

Flink+Alink,当大数据遇见机器学习!

博文视点Broadview

fil云算力系统开发具体流程丨fil云算力开发源码成品

系统开发咨询1357O98O718

带你认识大模型训练关键算法:分布式训练Allreduce算法

华为云开发者联盟

分布式训练 Allreduce算法 集合通信 分布式通信算法 大模型训练

NQI质量基础设施“一站式”服务平台开发解决方案

源中瑞-龙先生

开发 解决方案 NQI 质量基础设施“一站式”

你的同事是你的竞争对手吗?

石云升

战略思考 职场经验 6月日更

云网络开山之作,揭秘云上高速公路的十年技术成果!

博文视点Broadview

C 语言面向对象的封装方式

实力程序员

云上创新,阿里云视频云分享全场景音视频服务背后的场景探索与技术实践

阿里云视频云

阿里云 音视频 在线教育 视频会议 直播技术

拉仇恨!webhook + 企业微信给同事做了个代码提交监听工具

程序员小富

Java GitHub 编程 程序员 代码

Chia奇亚云算力挖矿系统开发成功案例丨Chia奇亚挖矿源码成品

系统开发咨询1357O98O718

华为云携手马栏山文创园助力湖南广电荣获国家广电总局多项大奖

华为云开发者联盟

AI 5G 视频 华为云 马栏山

【译】JavaScript 代码整洁之道-异常处理篇

KooFE

JavaScript 大前端 异常处理 6月日更 整洁代码

不要再依赖CommonJS了_语言 & 开发_Minko Gechev_InfoQ精选文章