一尘不染

NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack

javascript

试图总结我对最流行的 JavaScript 包管理器、捆绑器和任务运行器的了解。如果我错了,请纠正我:

  • npm&bower是包管理器。他们只是下载依赖项,不知道如何自己构建项目。他们所知道的是在获取所有依赖项之后调用webpack// gulpgrunt
  • bower就像npm,但是构建了一个扁平的依赖树(不像npm递归的那样)。含义npm为每个依赖项获取依赖项(可能会获取相同的几次),同时bower期望您手动包含子依赖项。有时bowernpm分别一起用于前端和后端(因为每兆字节在前端可能很重要)。
  • grunt并且gulp是自动化所有可以自动化的事情的任务运行者(即编译 CSS/Sass、优化图像、制作一个包并缩小/转换它)。
  • gruntvs. gulp(就像mavenvs.gradle或配置 vs. 代码)。Grunt 基于配置单独的独立任务,每个任务打开/处理/关闭文件。Gulp 需要更少的代码,并且基于 Node 流,这允许它构建管道链(无需重新打开同一个文件)并使其更快。
  • webpack( webpack-dev-server) - 对我来说,它是一个任务运行器,可以热重新加载更改,让您忘记所有 JS/CSS 观察者。
  • npm/ bower+ 插件可以替换任务运行器。他们的能力经常相交,所以如果你需要使用gulp/ gruntover npm+ 插件,会有不同的含义。但是任务运行器对于复杂的任务肯定更好(例如“在每次构建时创建包,从 ES6 转换到 ES5,在所有浏览器模拟器上运行它,制作屏幕截图并通过 ftp 部署到保管箱”)。
  • browserify允许为浏览器打包节点模块。browserifyvs实际上是nodeAMD vs CommonJSrequire

*问题:*

  1. 什么是webpack& webpack-dev-server官方文档说它是一个模块捆绑器,但对我来说它只是一个任务运行器。有什么不同?
  2. 你会在哪里使用browserify?我们不能对 node/ES6 导入做同样的事情吗?
  3. 你什么时候会使用gulp/ gruntover npm+ 插件?
  4. 当您需要使用组合时,请提供示例

阅读 162

收藏
2022-02-12

共1个答案

一尘不染

Webpack 和 Browserify

Webpack 和 Browserify 做了几乎相同的工作,即处理您的代码以在目标环境中使用(主要是浏览器,尽管您可以针对其他环境,如 Node)。这种处理的结果是一个或多个——适合目标环境的组装脚本。

例如,假设您编写了分成模块的 ES6 代码,并希望能够在浏览器中运行它。如果这些模块是 Node 模块,浏览器将无法理解它们,因为它们只存在于 Node 环境中。ES6 模块也无法在 IE11 等旧版浏览器中运行。此外,您可能使用了浏览器尚未实现的实验性语言功能(ES 下一个提案),因此运行此类脚本只会引发错误。Webpack 和 Browserify 等工具通过将此类代码转换为浏览器能够执行的形式来解决这些问题。最重要的是,它们可以在这些捆绑包上应用各种优化。

但是,Webpack 和 Browserify 有很多不同之处,Webpack 默认提供了很多工具(例如代码拆分),而 Browserify 只能在下载插件后才能做到这一点,但同时使用两者会导致非常相似的结果。这取决于个人喜好(Webpack 更时尚)。顺便说一句,Webpack 不是任务运行器,它只是文件的处理器(它通过所谓的加载器和插件处理它们)并且可以由任务运行器运行(以及其他方式)。


Webpack 开发服务器

Webpack Dev Server 提供了与 Browsersync 类似的解决方案 - 一个开发服务器,您可以在其中快速部署您的应用程序,并立即验证您的开发进度,开发服务器会在代码更改甚至传播更改的代码时自动刷新浏览器无需重新加载即可使用所谓的热模块更换浏览器。


任务运行器与 NPM 脚本

我一直在使用 Gulp,因为它简洁且易于编写任务,但后来发现我根本不需要 Gulp 和 Grunt。我所需要的一切都可以使用 NPM 脚本通过他们的 API 运行 3rd-party 工具来完成。在 Gulp、Grunt 或 NPM 脚本之间进行选择取决于团队的品味和经验。

虽然 Gulp 或 Grunt 中的任务即使对于不熟悉 JS 的人也很容易阅读,但它是另一种需要和学习的工具,我个人更喜欢缩小依赖关系并使事情变得简单。另一方面,将这些任务替换为 NPM 脚本和运行这些 3rd 方工具的(可能是 JS)脚本的组合(例如,节点脚本配置和运行rimraf以进行清理)可能更具挑战性。但在大多数情况下,这三者的结果是相同的。


例子

至于示例,我建议您看一下这个React 入门项目,它向您展示了 NPM 和 JS 脚本的完美组合,涵盖了整个构建和部署过程。您可以package.json在根文件夹中的一个名为scripts. 在那里,您主要会遇到类似babel-node tools/run start. Babel-node 是一个 CLI 工具(不适合生产使用),它首先编译 ES6 文件tools/run(位于tools的 run.js 文件) - 基本上是一个运行器实用程序。此运行程序将函数作为参数并执行它,在这种情况下是start- 另一个实用程序 (start.js) 负责捆绑源文件(客户端和服务器)并启动应用程序和开发服务器(开发服务器可能是 Webpack Dev Server 或 Browsersync)。

更准确地说,start.js创建客户端和服务器端捆绑包,启动快速服务器,并在成功启动后初始化 Browser-sync,在撰写本文时看起来像这样(请参阅react starter 项目以获取最新代码)。

const bs = Browsersync.create();  
bs.init({
      ...(DEBUG ? {} : { notify: false, ui: false }),

      proxy: {
        target: host,
        middleware: [wpMiddleware, ...hotMiddlewares],
      },

      // no need to watch '*.js' here, webpack will take care of it for us,
      // including full page reloads if HMR won't work
      files: ['build/content/**/*.*'],
}, resolve)

重要的部分是proxy.target,他们设置了他们想要代理的服务器地址,可以是http://localhost:3000,并且 Browsersync 启动一个服务器监听http://localhost:3001,生成的资产会自动更改检测和热模块更换。如您所见,还有另一个files带有单个文件或模式的配置属性 Browser-sync 监视更改并在发生某些更改时重新加载浏览器,但正如评论所说,Webpack 自己负责使用 HMR 监视 js 源,因此他们合作那里。

现在我没有任何类似的 Grunt 或 Gulp 配置示例,但是使用 Gulp(与 Grunt 有点类似)你可以在 gulpfile.js 中编写单个任务,例如

gulp.task('bundle', function() {
  // bundling source files with some gulp plugins like gulp-webpack maybe
});

gulp.task('start', function() {
  // starting server and stuff
});

您将在其中执行与初学者工具包中几乎相同的事情,这次使用任务运行程序,它为您解决了一些问题,但在学习使用过程中提出了自己的问题和一些困难,正如我所说,您拥有的依赖项越多,出错的可能性就越大。这就是我喜欢摆脱这些工具的原因。

2022-02-12