NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack [英] NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack

问题描述

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

• npm & bower 是包管理器。他们只是下载依赖关系，不知道如何自己构建项目。他们知道的是调用 webpack / gulp / grunt 在获取所有依赖关系之后。
  就像 npm ，但构建扁平化的依赖关系树（不同于 npm 递归地）。含义 npm 取得每个依赖项的依赖关系（可能会获取相同的几次），而 bower 需要手动包括子依赖关系。有时候 bower 和 npm 分别用于前端和后端（因为每兆字节可能在前端
  
• grunt 和 gulp 是任务运行器，可以自动执行所有操作这可以是自动化的（即编译CSS / Sass，优化图像，制作一个包并缩小/传输它）。 grunt vs vs 。 gulp （类似于 maven 与 gradle 或配置与代码）。 Grunt基于配置单独的独立任务，每个任务打开/处理/关闭文件。 Gulp需要的代码量较少，并且基于节点流，这使得它可以构建管道链（不重新打开相同的文件）并使其更快。


• webpack （ webpack-dev-server ） - 对我来说这是一个任务运行器，可以让你忘记所有的JS / CSS观察者。


• npm / bower +插件可能取代任务跑步者。他们的能力经常相交，所以如果你需要在以上使用 gulp / grunt npm +插件。但是对于复杂任务来说，任务运行者肯定更好（例如在每个构建中创建包，从ES6到ES5的转储，在所有浏览器模拟器上运行它，通过ftp制作截图并将其部署到Dropbox）。
  
• browserify 允许为浏览器打包节点模块。 browserify vs 节点的 require 实际上是 AMD vs CommonJS 。
  

问题： 什么是 webpack & webpack-dev-server ？官方文档说这是一个模块打包程序，但对我来说它只是一个任务运行程序。 我们不能对节点/ ES6导入进行相同的操作吗？

何时使用 gulp / grunt 超过 npm +插件

请提供您需要使用组合的例子

Webpack和Browserify几乎完成了相同的工作，处理要在目标环境中使用的代码（主要是浏览器，尽管您可以针对像Node这样的其他环境）。这种处理的结果是一个或多个捆绑包 - 适用于目标环境的汇编脚本。

例如，假设您编写了一个分为模块的ES6代码，并希望能够在浏览器中运行它。如果这些模块是Node模块，浏览器将不会理解它们，因为它们仅存在于Node环境中。 ES6模块在IE11等旧版浏览器中也不起作用。此外，您可能使用了浏览器尚未实现的实验性语言功能（ES下一个提议），因此运行此类脚本只会引发错误。像Webpack和Browserify这些工具通过将这些代码翻译成表单浏览器可以执行来解决这些问题。最重要的是，它们可以在这些包上应用各种各样的优化。

然而，Webpack和Browserify在很多方面有所不同，Webpack提供了许多工具默认情况下（例如代码分割），而Browserify只能在下载插件后才能做到这一点，但使用两者导致非常相似的结果。这归结于个人偏好（Webpack更时髦）。顺便说一句，Webpack不是任务运行者，它只是文件的处理器（它通过所谓的加载器和插件来处理它们），并且可以由任务运行器运行（以其他方式）。

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

---

任务执行者与NPM脚本

我一直在使用Gulp来简洁和简单的任务写作，但后来发现我根本不需要Gulp和Grunt。我所需要的一切都可以通过使用NPM脚本来完成，通过他们的API来运行第三方工具。 在Gulp，Grunt或NPM脚本之间进行选择取决于团队的品味和体验。

尽管Gulp或Grunt中的任务易于阅读对于不熟悉JS的人来说，它是另一种需要和学习的工具，我个人更倾向于缩小我的依赖关系并使事情变得简单。另一方面，将这些任务替换为运行这些第三方工具的NPM脚本和（propably JS）脚本的组合（例如，节点脚本配置和运行 rimraf 用于清洁目的）可能更具挑战性。但在大多数情况下，这三者在结果上是相同的。

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

更确切地说，start.js创建客户端和服务器端浏览器同步，在撰写本文时，看起来像这样（请参考为最新代码反应starter project）。

  const bs = Browsersync.create（）; 
 bs.init（{
 ...（DEBUG？{}：{notify：false，ui：false}），
 
代理：{
 target：主机，
中间件：[wpMiddleware，... hotMiddlewares]，
}，
 
 //不需要在这里观看'* .js'，webpack会照顾它对于我们来说，
 //如果HMR不起作用，包括整页重新加载$ ​​b $ b文件：['build / content /**/*.*']，
}，解析）
  

重要的部分是 proxy.target ，设置他们想要代理的服务器地址，可以是 http：// localhost：3000 ，Browsersync启动服务器，监听<一个href =http：// localhost：3001 =noreferrer> http：// localhost：3001 ，其中生成的资产配有自动更改检测和热模块更换。正如你所看到的，还有另外一个配置属性 files 具有单独的文件或模式浏览器同步监视器用于更改并重新加载浏览器（如果发生的话），但正如评论所说，Webpack照顾自己与HMR一起观看js资源，所以他们在那里合作。

现在我没有任何类似的Grunt或Gulp配置的例子，但是Gulp （和Grunt有点类似），你可以在gulpfile.js中写个别任务，比如

  gulp.task（'bundle'，function （）{
 //将源文件与一些gulp插件捆绑在一起，比如gulp-webpack也许
}）; 
 
 gulp.task（'start'，function（）{
 //启动服务器和东西
}）; 
  

在这里你可以做的基本上与starter-kit中的相同，这次任务运行者，这为你解决了一些问题，但是在学习使用过程中提出了自己的问题和一些困难，正如我所说的，你拥有的依赖性越多，错误越多。这就是我喜欢摆脱这些工具的原因。

I'm trying to summarize my knowledge about the most popular JavaScript package managers, bundlers, and task runners. Please correct me if I'm wrong:

• npm & bower are package managers. They just download the dependencies and don't know how to build projects on their own. What they know is to call webpack/gulp/grunt after fetching all the dependencies.
• bower is like npm, but builds flattened dependencies trees (unlike npm which do it recursively). Meaning npm fetches the dependencies for each dependency (may fetch the same a few times), while bower expects you to manually include sub-dependencies. Sometimes bower and npm are used together for front-end and back-end respectively (since each megabyte might matter on front-end).
• grunt and gulp are task runners to automate everything that can be automated (i.e. compile CSS/Sass, optimize images, make a bundle and minify/transpile it).
• grunt vs. gulp (is like maven vs. gradle or configuration vs. code). Grunt is based on configuring separate independent tasks, each task opens/handles/closes file. Gulp requires less amount of code and is based on Node streams, which allows it to build pipe chains (w/o reopening the same file) and makes it faster.
• webpack (webpack-dev-server) - for me it's a task runner with hot reloading of changes which allows you to forget about all JS/CSS watchers.
• npm/bower + plugins may replace task runners. Their abilities often intersect so there are different implications if you need to use gulp/grunt over npm + plugins. But task runners are definitely better for complex tasks (e.g. "on each build create bundle, transpile from ES6 to ES5, run it at all browsers emulators, make screenshots and deploy to dropbox through ftp").
• browserify allows packaging node modules for browsers. browserify vs node's require is actually AMD vs CommonJS.

Questions:

1. What is webpack & webpack-dev-server? Official documentation says it's a module bundler but for me it's just a task runner. What's the difference?
2. Where would you use browserify? Can't we do the same with node/ES6 imports?
3. When would you use gulp/grunt over npm + plugins?
4. Please provide examples when you need to use a combination

解决方案

Webpack and Browserify

Webpack and Browserify do pretty much the same job, which is processing your code to be used in a target environment (mainly browser, though you can target other environments like Node). Result of such processing is one or more bundles - assembled scripts suitable for targeted environment.

For example, let's say you wrote an ES6 code divided into modules and want be able to run it in browser. If those modules are Node modules, browser won't understand them since they exist only in Node environment. ES6 modules also won't work in older browsers like IE11. Moreover you might have used experimental language features (ES next proposals) that browsers don't implement yet so running such script would just throw errors. Those tools like Webpack and Browserify solve these problems by translating such code to a form browser is able to execute. On top of that, they make it possible to apply a huge variety of optimisations on those bundles.

However, Webpack and Browserify differ in many ways, Webpack offers many tools by default (e.g. code splitting), while Browserify can do this only after downloading plugins but using both leads to very similar results. It comes down to personal preference (Webpack is trendier). Btw, Webpack is not a task runner, it is just processor of your files (it processes them by so called loaders and plugins) and it can be run (among other ways) by a task runner.

---

Webpack Dev Server

Webpack Dev Server provides similar solution to Browsersync - a development server where you can deploy your app rapidly as you are working on it, and verify your development progress immediately with the dev server automatically refreshing the browser on code changes or even propagating changed code to browser without reloading with so called hot module replacement.

---

Task runners vs NPM scripts

I've been using Gulp for its conciseness and easy task writing, but have later found out I need neither Gulp nor Grunt at all. Everything I have ever needed could have been done using NPM scripts to run 3rd-party tools through their API. Choosing between Gulp, Grunt or NPM scripts depends on taste and experience of your team.

While tasks in Gulp or Grunt are easy to read even for people not so familiar with JS, it is yet another tool to require and learn and I personally prefer to narrow my dependencies and make things simple. On the other hand, replacing these tasks with the combination of NPM scripts and (propably JS) scripts which run those 3rd party tools (eg. Node script configuring and running rimraf for cleaning purposes) might be more challenging. But in the majority of cases, those three are equal in terms of results.

---

Examples

As for the examples, I suggest you have a look at this React starter project, which shows you a nice combination of NPM and JS scripts covering the whole build and deploy process. You can find those NPM scripts in package.json in the root folder, in a property named scripts. There you will mostly encounter commands like babel-node tools/run start. Babel-node is a CLI tool (not meant for production use), which at first compiles ES6 file tools/run (run.js file located in tools) - basically a runner utility. This runner takes a function as an argument and executes it, which in this case is start - another utility (start.js) responsible for bundling source files (both client and server) and starting the application and development server (the dev server will be probably either Webpack Dev Server or Browsersync).

Speaking more precisely, start.js creates both client and server side bundles, starts express server and after successful start inits Browser-sync, which at the time of writing looked like this (please refer to react starter project for the newest code).

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)

The important part is proxy.target, where they set server address they want to proxy, which could be http://localhost:3000, and Browsersync starts a server listening on http://localhost:3001, where the generated assets are served with automatic change detection and hot module replacement. As you can see, there is another configuration property files with individual files or patterns Browser-sync watches for changes and reloads the browser if some occur, but as the comment says, Webpack takes care of watching js sources by itself with HMR, so they cooperate there.

Now I don't have any equivalent example of such Grunt or Gulp configuration, but with Gulp (and somewhat similarly with Grunt) you would write individual tasks in gulpfile.js like

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

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

where you would be doing essentially pretty much the same things as in the starter-kit, this time with task runner, which solves some problems for you, but presents its own issues and some difficulties during learning the usage, and as I say, the more dependencies you have, the more can go wrong. And that is the reason I like to get rid of such tools.

这篇关于NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！