原文链接: www.cross-platform-blog.com
翻译链接:https://www.zcfy.cc/article/interview-with-webpack-founder-tobias-koppers
Tobias Koppers是一位自由软件开发者,家住德国纽伦堡。他因写出webpack这个已有数百万开发者使用的开源软件而名噪一时。他目前专注于JavaScript和开源项目。以下是我对他个人的专访,希望对大家有所启发。
Gregor:你好,Tobias,JavaScript社区都在谈论webpack,就连谷歌也已经把它集成到了自己的Angular CLI项目中了。很高兴webpack诞生于纽伦堡,离我的老家英戈尔施塔特(德国)不远。跟我们分享一下,你当时怎么想起来写webpack的,它怎么那么快就受到了大家欢迎的?
Tobias:你好,Gregor。实际上,谷歌也在参与webpack的开发,只不过是间接参与。我在迷上JavaScript以上,也写过Java。谷歌曾经推出过一个工具,叫GWT(Google Web Toolkit),让Java程序员能用Java编写客户端应用。GWT其实是一个Java应用到JavaScript SPA的编译器,也使用了谷歌的一些应用。
GWT有一个功能我研究了很长时间,就是代码拆分(code splitting)。这个功能可以延迟加载不常用的代码。对于要保持初始加载速度的大型应用,这个功能非常重要。但我没发现JavaScript的开源工具(2012年)中哪个具备这个功能,于是我就想写一个这样的工具,也就是webpack。
换句话说,webpack诞生之初主要想解决代码拆分的问题。而在我看来,这也是webpack今天这么受欢迎的原因所在。随着Web应用越写越大,而移动设备越来越普及(但上网环境相对不好),拆分代码的需求与日俱增。如果不拆分代码,就很难实现期望的性能。
Gregor:很多人拿webpack跟npm脚本、Grunt和Gulp等进行比较。有人也确实通过webpack实现那些工具的功能。我以后也会使用NPM脚本和webpack。你对此怎么看,你除了webpack之外,还会用其他任务工具吗?
Tobias: NPM脚本对我而言足矣。实际上,说webpack是Grunt/Gulp的替代器并不完全准确。Grunt和Gulp以及NPM脚本都是任务执行程序。
Webpack是模块打包程序。这两类程序的目标不一样。但webpack简化了 必须“过度使用”Grunt和Gulp和NPM脚本才能实现的Web开发任务也是事实。NPM脚本才是Grunt和Gulp的替代品。
不过,除了纯粹的构建之外,任务运行程序也有存在的理由,比如部署、代码检查、版本管理,等等。
Gregor:在我的JavaScript培训课上,很多学员都说webpack上手有多难多难。有没有也人跟说这么说过?如果有,你有没有想过怎么改进?
Tobias: 有,确实有这样的反馈。不过,也有不少用户在会用以后还这么说。而实际上webpack使用起来很简单。只要会写网页,都会觉得它比之前的工具容易使用。
我认为这些反馈主要是因为webpack的概念与其他工具的概念明显不一样,特别是在把Grunt/Gulp迁移到webpack时。任务运行程序的配置是指令式的,描述的是每一步要执行什么任务。而Webpack的配置则是声明式的,就是说不会描述webpack要执行的步骤,而只描述执行这些步骤的方式或执行后的结果是什么样的。
Gregor: 你的开发日程是怎么安排的?下一个webpack的版本计划有什么功能?
Tobias: 现在还说不太好。很多事情都有可能,捡几个重要的说一下吧:
用户和赞助者决定实现这些功能的优先级。我建了一个投票页面,大家可以去投。所有人都可以表达自己的想法,但赞助者和志愿者的权重更大。因为他们需要一定的回报。用户当然希望多多益善。
Gregor:能否推荐几个webpack最佳实践?
Tobias: 使用按需加载。非常简单,效果非常好。
Gregor:你个人有什么目标吗?我们会不会很快在媒体上看到,说你去谷歌去山景城了?
Tobias: 我不这样想。我很快会成为一个自由职业者。我会把更多的时间放到开源上来,通过捐助实现财务平衡。因为捐赠通常不够,我会接一些工作或咨询来弥补缺口。我很想知道这样行不行。也许有人会成为我的赞助商,提供额外几个星期的赞助(听见了吗,谷歌)。
维护一个开源项目需要付出的努力超出常人想象。现在,代码评审和解决issuse占了我80%时间。我既没足够的时间写代码,也没时间重构。甚至一些合并请求我都得拖上一段时间才能处理。我需要花时间仔细看一看。当然,志愿者并不想如此。我想这种情况会变的,只要我全职写webpack就行了。但愿我能有更多时间写更多代码。
Gregor:非常感谢你接受采访!也感谢webpack,感谢它对JavaScript开发者的大力支持。非常喜欢你这个工具!
Tobias: 不客气。我要感谢社区。Webpack并不是“我的”工具,它是500多位志愿者共同的成果。Webpacks成功也是源于这个伟大的生态。
随着前端项目复杂程度越来越高,依赖也越来越多,为了提高项目中代码的可复用性,前端开始提出模块化开发的思路,前端模块化会有以下几个痛点:命名冲突,文件依赖,代码复用
webpack 只能理解 JavaScript 和 JSON 文件。loader 让 webpack 能够去处理其他类型的文件,并将它们转换为有效模块,以供应用程序使用,以及被添加到依赖图中。
nodejs的出现对于构建工具具有重要的意义,在没有nodejs之前,js只能执行在浏览器环境下,所以意味着对发布前的js文件要进行处理,十分局限,没有打包工具,只能用PHP脚本来处理文件
webpack 是一个模块打包器,在它看来,每一个文件都是一个模块。无论你开发使用的是 CommonJS 规范还是 ES6 模块规范,打包后的文件都统一使用 webpack 自定义的模块规范来管理、加载模块
本文从一个小Demo开始,通过不断增加功能来说明webpack的基本配置,只针对新手。webpack基本的配置就可以熟悉了,会引入loader,配置loader选项,会设置alias,会用plugins差不多。
webpack 插件是一个具有 apply 属性的 JavaScript 对象。apply 属性会被 webpack compiler 调用,并且 compiler 对象可在整个编译生命周期访问
Webpack中loader是一个CommonJs风格的函数,接收输入的源码,通过同步或异步的方式替换源码后进行输出。需要注意的是,该导出函数必须使用function,不能使用箭头函数,因为loader编写过程中会经常使用到this访问选项和其他方法。
本文讲述css-loader开启css模块功能之后,如何与引用的npm包中样式文件不产生冲突。比如antd-mobilenpm包的引入。在不做特殊处理的前提下,样式文件将会被转译成css module。
webpack本身只能打包Javascript文件,对于其他资源例如 css,图片,或者其他的语法集比如jsx,是没有办法加载的。 这就需要对应的loader将资源转化,加载进来。
tapable是webpack的核心依赖库 想要读懂webpack源码 就必须首先熟悉tapable。ok.下面是webapck中引入的tapable钩子 由此可见 在webpack中tapable的重要性
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!