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

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

6 个月前关闭。



Improve this question




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

npm & bower是包管理器。他们只是下载依赖项，不知道如何自己构建项目。他们知道的就是拨打webpack/gulp/grunt获取所有依赖项后。

bower就像 npm ，但会构建一个扁平化的依赖树(与 npm 不同，它以递归方式进行)。意义 npm获取每个依赖的依赖(可能多次获取相同的)，而 bower期望您手动包含子依赖项。有时 bower和 npm分别用于前端和后端(因为每兆字节在前端可能很重要)。

grunt和 gulp是任务运行器来自动化所有可以自动化的东西(即编译 CSS/Sass，优化图像，制作一个包并缩小/转译它)。

grunt对比 gulp (就像 maven 与 gradle 或配置与代码)。 Grunt 基于配置单独的独立任务，每个任务打开/处理/关闭文件。 Gulp 需要更少的代码并且基于 Node 流，这允许它构建管道链(无需重新打开同一个文件)并使其更快。

webpack ( webpack-dev-server ) - 对我来说，它是一个带有热重载更改的任务运行器，它允许您忘记所有 JS/CSS 观察器。

npm/bower + 插件可能会取代任务运行器。它们的能力经常相交，因此如果您需要使用 gulp 会有不同的含义。/grunt在 npm + 插件。但是任务运行器对于复杂的任务肯定更好(例如“在每个构建中创建包，从 ES6 转换到 ES5，在所有浏览器模拟器上运行它，制作屏幕截图并通过 ftp 部署到 dropbox”)。

browserify允许为浏览器打包节点模块。 browserify对比 node的 require实际上是 AMD vs CommonJS .

问题:

什么是webpack & webpack-dev-server ?官方文档说它是一个模块捆绑器，但对我来说它只是一个任务运行器。有什么不同？

您会在哪里使用 browserify ?我们不能对 node/ES6 导入做同样的事情吗？

你什么时候用 gulp/grunt在 npm + 插件？

需要使用组合时请举例说明

Answer 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 方工具来完成。 在 Gulp、Grunt 或 NPM 脚本之间进行选择取决于您团队的品味和经验。

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

例子

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

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

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 ，其中生成的 Assets 具有自动更改检测和热模块替换功能。如您所见，还有另一个配置属性 files对于单个文件或模式，浏览器同步会监视更改并在发生更改时重新加载浏览器，但正如评论所说，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
});

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