NPM，Bower，Browserify，Gulp，Grunt，Webpack

本文翻译自：NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack

I'm trying to summarize my knowledge about the most popular JavaScript package managers, bundlers, and task runners. 我试图总结我对最流行的JavaScript包管理器，捆绑器和任务运行器的了解。 Please correct me if I'm wrong: 如果我错了，请纠正我：

npm & bower are package managers. npm和bower是程序包管理器。 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. 他们知道什么是调用webpack / gulp / grunt获取所有的依赖后。
bower is like npm , but builds flattened dependencies trees (unlike npm which do it recursively). bower就像npm一样，但是建立了扁平的依赖关系树（不像npm那样递归地执行）。 Meaning npm fetches the dependencies for each dependency (may fetch the same a few times), while bower expects you to manually include sub-dependencies. 意思是npm获取每个依赖关系的依赖关系（可能会获取相同的几次），而bower希望您手动包括子依赖关系。 Sometimes bower and npm are used together for front-end and back-end respectively (since each megabyte might matter on front-end). 有时， bower和npm分别用于前端和后端（因为每个兆字节在前端可能很重要）。
grunt and gulp are task runners to automate everything that can be automated (ie compile CSS/Sass, optimize images, make a bundle and minify/transpile it). grunt和gulp是使所有可以自动化的工作自动化的任务执行者（即，编译CSS / Sass，优化图像，制作捆绑包以及缩小/翻译它）。
grunt vs. gulp (is like maven vs. gradle or configuration vs. code). grunt与gulp （就像是maven与gradle或配置与代码）。 Grunt is based on configuring separate independent tasks, each task opens/handles/closes file. Grunt基于配置单独的独立任务，每个任务打开/处理/关闭文件。 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. Gulp需要较少的代码量，并且基于Node流，这使其可以构建管道链（无需重新打开同一文件）并使其更快。
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. webpack （ webpack-dev-server ）-对我来说，这是一个任务执行程序，它具有对更改进行热加载的功能，使您webpack webpack-dev-server所有JS / CSS监视程序。
npm / bower + plugins may replace task runners. npm / bower +插件可以代替任务运行器。 Their abilities often intersect so there are different implications if you need to use gulp / grunt over npm + plugins. 它们的能力经常相交，因此如果您需要在npm +插件上使用gulp / grunt ，则会有不同的含义。 But task runners are definitely better for complex tasks (eg "on each build create bundle, transpile from ES6 to ES5, run it at all browsers emulators, make screenshots and deploy to dropbox through ftp"). 但是任务运行者绝对适合复杂任务（例如“在每个构建中创建捆绑包，从ES6移植到ES5，在所有浏览器模拟器上运行它，制作屏幕截图并通过ftp部署到保管箱”）。
browserify allows packaging node modules for browsers. browserify允许打包浏览器的节点模块。 browserify vs node 's require is actually AMD vs CommonJS . browserify vs node的require实际上是AMD vs CommonJS 。

Questions: 问题：

What is webpack & webpack-dev-server ? 什么是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? 有什么不同？
Where would you use browserify ? 您将在哪里使用browserify ？ Can't we do the same with node/ES6 imports? 我们不能对node / ES6导入做同样的事情吗？
When would you use gulp / grunt over npm + plugins? 您何时会在npm +插件上使用gulp / grunt ？
Please provide examples when you need to use a combination 当您需要组合使用时，请提供示例

#1楼

参考：https://stackoom.com/question/2N7Rs/NPM-Bower-Browserify-Gulp-Grunt-Webpack

#2楼

Webpack and Browserify Webpack和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). Webpack和Browserify几乎完成了相同的工作，即处理要在目标环境 （主要是浏览器，尽管您可以将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. 例如，假设您编写了一个分为模块的ES6代码，并希望能够在浏览器中运行它。 If those modules are Node modules, browser won't understand them since they exist only in Node environment. 如果这些模块是Node模块，则浏览器将无法理解它们，因为它们仅存在于Node环境中。 ES6 modules also won't work in older browsers like IE11. ES6模块也无法在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. 此外，您可能使用了浏览器尚未实现的实验语言功能（ES的下一个建议），因此运行此类脚本只会引发错误。 Those tools like Webpack and Browserify solve these problems by translating such code to a form browser is able to execute . 诸如Webpack和Browserify之类的工具通过将此类代码转换为浏览器能够执行的形式来解决这些问题。 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 (eg code splitting), while Browserify can do this only after downloading plugins but using both leads to very similar results . 但是，Webpack和Browserify在许多方面有所不同，Webpack默认提供许多工具（例如，代码拆分），而Browserify仅在下载插件后才能执行此操作，但使用这两种方法会导致非常相似的结果 。 It comes down to personal preference (Webpack is trendier). 它归结为个人喜好（Webpack更为流行）。 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不是任务运行程序，它只是文件的处理器（它通过所谓的加载程序和插件来处理文件），并且可以由任务运行程序（其他方式）运行。

Webpack Dev Server Webpack开发服务器

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. Webpack Dev Server提供了与Browsersync类似的解决方案-一种开发服务器，您可以在开发过程中快速部署应用程序，并通过开发服务器立即根据代码更改自动刷新浏览器甚至将更改的代码传播到浏览器，从而验证开发进度无需重新加载所谓的热模块更换。

Task runners vs NPM scripts 任务运行程序与NPM脚本

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. 我一直在使用Gulp的简洁性和易于编写的任务，但是后来发现我根本不需要Gulp或Grunt。 Everything I have ever needed could have been done using NPM scripts to run 3rd-party tools through their API. 使用NPM脚本通过其API运行第三方工具，我曾经需要的一切都可以完成。 Choosing between Gulp, Grunt or NPM scripts depends on taste and experience of your team. 在Gulp，Grunt或NPM脚本之间进行选择取决于团队的品味和经验。

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. 尽管即使对于不那么熟悉JS的人来说，Gulp或Grunt的任务也很容易阅读，但它是又一个需要学习的工具，我个人更喜欢缩小依赖范围并使事情变得简单。 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. 另一方面，用NPM脚本和运行那些第3方工具（例如，为清洁目的配置Node脚本并运行rimraf ）的NPM脚本和（可能是JS）脚本的组合来替换这些任务可能更具挑战性。 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. 对于示例，我建议您看一下这个React starter项目，该项目向您展示了NPM和JS脚本的完美结合，涵盖了整个构建和部署过程。 You can find those NPM scripts in package.json in the root folder, in a property named scripts . 您可以在根文件夹的package.json中的名为scripts的属性中找到这些NPM scripts 。 There you will mostly encounter commands like babel-node tools/run start . 在那里，您通常会遇到诸如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. Babel-node是一个CLI工具（不适用于生产用途），首先会编译ES6文件tools/run （位于tools中的 run.js文件）-本质上是一个运行器实用程序。 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). 这个运行需要一个函数作为参数并执行它，在这种情况下是start -其他实用工具（start.js）负责绑定的源文件（客户端和服务器），并启动应用程序和开发服务器（开发服务器会可能是Webpack开发服务器或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). 准确地说，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)

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. 重要的部分是proxy.target ，他们在其中设置要代理的服务器地址，该地址可以是http：// localhost：3000 ，并且Browsersync启动一个服务器侦听http：// localhost：3001 ，在该服务器中提供生成的资产具有自动更改检测和热模块更换功能。 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. 如您所见，还有另一个带有单个文件或模式的配置属性files ，浏览器同步监视更改并在发生某些更改时重新加载浏览器，但是正如评论所述，Webpack会通过HMR自行监视js源，因此它们在那里合作。

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 现在我没有任何类似的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
});

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. 这就是我喜欢摆脱此类工具的原因。

#3楼

A small note about npm: npm3 tries install dependencies in a flat way 关于npm的小提示：npm3尝试以扁平方式安装依赖项

https://docs.npmjs.com/how-npm-works/npm3#npm-v3-dependency-resolution https://docs.npmjs.com/how-npm-works/npm3#npm-v3-dependency-resolution

#4楼

You can find some technical comparison on npmcompare 您可以在npmcompare上找到一些技术比较

Comparing browserify vs. grunt vs. gulp vs. webpack 比较Browserify，Grunt，Gulp和Webpack

As you can see webpack is very well maintained with a new version coming out every 4 days on average. 如您所见，webpack维护得很好，平均每4天就会发布一个新版本。 But Gulp seems to have the biggest community of them all (with over 20K stars on Github) Grunt seems a bit neglected (compared to the others) 但是Gulp似乎拥有最大的社区（Github上有超过2万颗星）Grunt似乎被忽略了（与其他人相比）

So if need to choose one over the other i would go with Gulp 因此，如果需要选择一个，我会选择Gulp

#5楼

Update October 2018 2018年10月更新

If you are still uncertain about Front-end dev, can take a quick look into an excellent resource here. 如果您仍然不确定Front-end开发人员，可以在这里快速查看出色的资源。

https://github.com/kamranahmedse/developer-roadmap https://github.com/kamranahmedse/developer-roadmap

Update June 2018 2018年6月更新

Learning modern JavaScript is tough if you haven't been there since the beginning. 如果您从一开始就没有去过那里，那么学习现代JavaScript将会很困难。 If you are the new comer, remember to check this excellent written to have a better overview. 如果您是新手，请记得阅读这篇出色的文章，以获得更好的概述。

https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70 https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70

Update July 2017 2017年7月更新

Recently I found a really comprehensive guide from Grab team about how to approach front-end development in 2017. You can check it out as below. 最近，我从Grab团队那里找到了一份非常全面的指南，内容涉及如何在2017年进行前端开发。您可以按照以下方法进行检查。

https://github.com/grab/front-end-guide https://github.com/grab/front-end-guide

I've been also searching for this quite some time since there is a lot of tools out there and each of them benefits us in a different aspect. 我也一直在寻找这个时间，因为那里有很多工具，并且每个工具都在不同方面使我们受益。 The community is divided across tools like Browserify, Webpack, jspm, Grunt and Gulp . 该社区分为各种工具，例如Browserify, Webpack, jspm, Grunt and Gulp 。 You might also hear about Yeoman or Slush . 您可能还会听说Yeoman or Slush 。 That's not really a problem, it's just confusing for everyone trying to understand a clear path forward. 这并不是一个真正的问题，只是让每个试图理解一条清晰道路的人感到困惑。

Anyway, I would like to contribute something. 无论如何，我想贡献一点。

1. Package Manager 1.包管理器

Package managers simplify installing and updating project dependencies, which are libraries such as: jQuery, Bootstrap , etc - everything that is used on your site and isn't written by you. 程序包管理器简化了项目依赖项的安装和更新，这些依赖项是诸如jQuery, Bootstrap类的库-站点上使用的所有内容，而不是您编写的。

Browsing all the library websites, downloading and unpacking the archives, copying files into the projects — all of this is replaced with a few commands in the terminal. 浏览所有图书馆网站，下载和解压缩档案，将文件复制到项目中-所有这些都由终端中的一些命令代替。

NPM stands for: Node JS package manager helps you to manage all the libraries your software relies on. NPM代表： Node JS package manager可帮助您管理软件所依赖的所有库。 You would define your needs in a file called package.json and run npm install in the command line... then BANG, your packages are downloaded and ready to use. 您将在一个名为package.json的文件中定义您的需求，并在命令行中运行npm install ...然后，BANG，您的软件包已下载并可以使用。 Could be used both for front-end and back-end libraries. 既可以用于front-end and back-end库，也可以用于front-end and back-end库。
Bower : for front-end package management, the concept is same with NPM. Bower ：对于前端软件包管理，其概念与NPM相同。 All your libraries are stored in a file named bower.json and then run bower install in the command line. 您所有的库都存储在名为bower.json的文件中，然后在命令行中运行bower install 。

The biggest difference between Bower and NPM is that NPM does nested dependency tree while Bower requires a flat dependency tree as below. Bower和NPM之间的最大区别是NPM确实嵌套了依赖树，而Bower需要如下所示的平面依赖树。

Quoting from What is the difference between Bower and npm? 引用Bower和npm有什么区别？

NPM NPM

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A 
    -> dependency D

Bower 凉亭

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

There are some updates on npm 3 Duplication and Deduplication , please open the doc for more detail. npm 3 Duplication and Deduplication上有一些更新，请打开文档以获取更多详细信息。

Yarn : A new package manager for JavaScript published by Facebook recently with some more advantages compared to NPM . Yarn ： Facebook 发行的一种新的JavaScript软件包管理器，与NPM相比，它具有更多优势。 And with Yarn, you still can use both NPM and Bower registry to fetch the package. 使用Yarn，您仍然可以同时使用NPM和Bower注册表来获取软件包。 If you've installed a package before, yarn creates a cached copy which facilitates offline package installs . 如果您以前安装过软件包，则yarn会创建一个缓存的副本，以方便offline package installs 。
jspm : is a package manager for the SystemJS universal module loader, built on top of the dynamic ES6 module loader. jspm ：是在动态ES6模块加载器之上构建的SystemJS通用模块加载器的软件包管理器。 It is not an entirely new package manager with its own set of rules, rather it works on top of existing package sources. 它不是具有自己的一组规则的全新软件包管理器，而是可以在现有软件包源之上运行。 Out of the box, it works with GitHub and npm . 开箱即用，它可以与GitHub和npm 。 As most of the Bower based packages are based on GitHub , we can install the those packages using jspm as well. 由于大多数基于Bower的软件包都基于GitHub ，因此我们也可以使用jspm安装这些软件包。 It has a registry that lists most of the commonly used front-end packages for easier installation. 它有一个注册表，其中列出了大多数常用的前端软件包，以便于安装。

See the different between Bower and jspm : Package Manager: Bower vs jspm 看到Bower和jspm之间的区别：程序包管理器：Bower vs jspm

2. Module Loader/Bundling 2.模块加载器/捆绑

Most projects of any scale will have their code split between a number of files. 任何规模的大多数项目的代码都将分为多个文件。 You can just include each file with an individual <script> tag, however, <script> establishes a new http connection, and for small files – which is a goal of modularity – the time to set up the connection can take significantly longer than transferring the data. 您可以只在每个文件中包含一个单独的<script>标记，但是<script>建立一个新的http连接，对于小型文件（这是模块化的目标），建立连接的时间可能比传输要长得多。数据。 While the scripts are downloading, no content can be changed on the page. 在下载脚本时，无法在页面上更改任何内容。

The problem of download time can largely be solved by concatenating a group of simple modules into a single file, and minifying it. 下载时间问题可以通过将一组简单模块串联到一个文件中并进行最小化来解决。

Eg 例如

<head>
    <title>Wagon</title>
    <script src=“build/wagon-bundle.js”></script>
</head>

The performance comes at the expense of the flexibility though. 但是，性能是以牺牲灵活性为代价的。 If your modules have inter-dependency, this lack of flexibility may be a showstopper. 如果您的模块具有相互依赖性，则缺乏灵活性可能会成为热门。

Eg 例如

<head>
    <title>Skateboard</title>
    <script src=“connectors/axle.js”></script>
    <script src=“frames/board.js”></script>
    <!-- skateboard-wheel and ball-bearing both depend on abstract-rolling-thing -->
    <script src=“rolling-things/abstract-rolling-thing.js”></script>
    <script src=“rolling-things/wheels/skateboard-wheel.js”></script>
    <!-- but if skateboard-wheel also depends on ball-bearing -->
    <!-- then having this script tag here could cause a problem -->
    <script src=“rolling-things/ball-bearing.js”></script>
    <!-- connect wheels to axle and axle to frame -->
    <script src=“vehicles/skateboard/our-sk8bd-init.js”></script>
</head>

Computers can do that better than you can, and that is why you should use a tool to automatically bundle everything into a single file. 计算机可以比您做的更好，这就是为什么您应该使用工具将所有内容自动捆绑到一个文件中的原因。

Then we heard about RequireJS , Browserify , Webpack and SystemJS 然后我们听说了RequireJS ， Browserify ， Webpack和SystemJS

RequireJS : is a JavaScript file and module loader. RequireJS ：是一个JavaScript文件和模块加载器。 It is optimized for in-browser use, but it can be used in other JavaScript environments, like Node . 它针对浏览器内使用进行了优化，但可以在其他JavaScript环境中使用，例如Node 。

Eg: myModule.js 例如： myModule.js

// package/lib is a dependency we require
define(["package/lib"], function (lib) {

    // behavior for our module
    function foo() {
        lib.log( "hello world!" );
    }

    // export (expose) foo to other modules as foobar
    return {
        foobar: foo
    }
});

In main.js , we can import myModule.js as dependency and use it. 在main.js ，我们可以将myModule.js导入为依赖项并使用它。

require(["package/myModule"], function(myModule) {
    myModule.foobar();
});

And then in our HTML , we can refer to use with RequireJS . 然后在我们的HTML ，我们可以使用RequireJS进行引用。

<script src=“app/require.js” data-main=“main.js” ></script>

Read more about CommonJS and AMD to get understanding easily. 阅读有关CommonJS和AMD更多信息以轻松理解。 Relation between CommonJS, AMD and RequireJS? CommonJS，AMD和RequireJS之间的关系？

Browserify : set out to allow use of CommonJS formatted modules in the browser. Browserify ：允许在浏览器中使用CommonJS格式的模块。 Consequently, Browserify isn't as much a module loader as a module bundler: Browserify is entirely a build-time tool, producing a bundle of code which can then be loaded client-side. 因此， Browserify是模块捆绑器， Browserify是模块加载器： Browserify完全是一个构建时工具，可以生成一捆代码，然后可以在客户端进行加载。

Start with a build machine that has node & npm installed, and get the package: 从安装了node＆npm的构建机器开始，并获取软件包：

npm install -g –save-dev browserify

Write your modules in CommonJS format 以CommonJS格式编写模块

//entry-point.js
var foo = require('../foo.js');
console.log(foo(4));

And when happy, issue the command to bundle: 并在高兴时发出捆绑命令：

browserify entry-point.js -o bundle-name.js

Browserify recursively finds all dependencies of entry-point and assembles them into a single file: Browserify递归地找到入口点的所有依赖项，并将它们组合成一个文件：

<script src=”bundle-name.js”></script>

Webpack : It bundles all of your static assets, including JavaScript , images, CSS and more, into a single file. Webpack ：它将您的所有静态资产（包括JavaScript ，图像，CSS等）捆绑到一个文件中。 It also enables you to process the files through different types of loaders. 它还使您能够通过不同类型的加载程序来处理文件。 You could write your JavaScript with CommonJS or AMD modules syntax. 您可以使用CommonJS或AMD模块语法编写JavaScript 。 It attacks the build problem in a fundamentally more integrated and opinionated manner. 它从根本上更加集成和自觉地攻击了构建问题。 In Browserify you use Gulp/Grunt and a long list of transforms and plugins to get the job done. 在Browserify您可以使用Gulp/Grunt和一长串的转换和插件来完成工作。 Webpack offers enough power out of the box that you typically don't need Grunt or Gulp at all. Webpack开箱即Webpack提供了足够的功能，您通常根本不需要Grunt或Gulp 。

Basic usage is beyond simple. 基本用法非常简单。 Install Webpack like Browserify: 像Browserify一样安装Webpack：

npm install -g –save-dev webpack

And pass the command an entry point and an output file: 并向命令传递一个入口点和一个输出文件：

webpack ./entry-point.js bundle-name.js

SystemJS : is a module loader that can import modules at run time in any of the popular formats used today ( CommonJS, UMD, AMD, ES6 ). SystemJS ：是一个模块加载器， 可以在运行时以当今使用的任何流行格式 （ CommonJS, UMD, AMD, ES6 ） 导入模块 。 It is built on top of the ES6 module loader polyfill and is smart enough to detect the format being used and handle it appropriately. 它建立在ES6模块加载器polyfill之上，并且足够智能，可以检测到所使用的格式并进行适当处理。 SystemJS can also transpile ES6 code (with Babel or Traceur ) or other languages such as TypeScript and CoffeeScript using plugins. SystemJS还可以使用插件来转换ES6代码（使用Babel或Traceur ）或其他语言，例如TypeScript和CoffeeScript 。

Want to know what is the node module and why it is not well adapted to in-browser. 想知道什么是node module以及为什么它不适用于浏览器。

More useful article: 更有用的文章：

https://medium.com/@housecor/browserify-vs-webpack-b3d7ca08a0a9#.c1q7ao3h4 https://medium.com/@housecor/browserify-vs-webpack-b3d7ca08a0a9#.c1q7ao3h4

http://jamesknelson.com/which-build-system-should-i-use-for-my-javascript-app/ http://jamesknelson.com/which-build-system-should-i-use-for-my-javascript-app/

https://appendto.com/2016/06/the-short-history-of-javascript-module-loaders/ https://appendto.com/2016/06/the-short-history-of-javascript-module-loaders/

Why jspm and SystemJS ? 为什么选择jspm和SystemJS ？

One of the main goals of ES6 modularity is to make it really simple to install and use any Javascript library from anywhere on the Internet ( Github , npm , etc.). ES6模块化的主要目标之一是使从Internet上任何地方（ Github ， npm等）安装和使用任何Javascript库的过程变得非常简单。 Only two things are needed: 只需要两件事：

A single command to install the library 单个命令即可安装库

One single line of code to import the library and use it 一行代码即可导入库并使用它

So with jspm , you can do it. 因此，使用jspm ，您可以做到。

Install the library with a command: jspm install jquery 使用以下命令安装库： jspm install jquery

Import the library with a single line of code, no need to external reference inside you HTML file. 只需单行代码即可导入库，而无需在HTML文件内部进行外部引用。

display.js display.js
 var $ = require('jquery'); $('body').append("I've imported jQuery!"); 
Then you configure these things within System.config({ ... }) before importing your module. 然后，在导入模块之前，请在System.config({ ... })配置这些内容。 Normally when run jspm init , there will be a file named config.js for this purpose. 通常，在运行jspm init ，将有一个名为config.js的文件用于此目的。

To make these scripts run, we need to load system.js and config.js on the HTML page. 为了使这些脚本运行，我们需要在HTML页面上加载system.js和config.js 。 After that we will load the display.js file using the SystemJS module loader. 之后，我们将使用SystemJS模块加载器加载display.js文件。

index.html index.html
 <script src="jspm_packages/system.js"></script> <script src="config.js"></script> <script> System.import("scripts/display.js"); </script> 
Noted: You can also use npm with Webpack as Angular 2 has applied it. 注意：Angular 2已将npm与Webpack一起使用。 Since jspm was developed to integrate with SystemJS and it works on top of existing npm source, so your answer is up to you. 由于jspm是为与SystemJS集成而开发的，并且可以在现有npm源代码之上npm ，因此您的答案取决于您。

3. Task runner 3.任务执行器

Task runners and build tools are primarily command-line tools. 任务运行器和构建工具主要是命令行工具。 Why we need to use them: In one word: automation . 为什么需要使用它们：一句话： 自动化 。 The less work you have to do when performing repetitive tasks like minification, compilation, unit testing, linting which previously cost us a lot of times to do with command line or even manually. 在执行诸如缩小，编译，单元测试，整理等重复性任务时，您以前要做的工作较少，而以前使用命令行甚至手动进行这些工作花费了我们很多时间。

Grunt : You can create automation for your development environment to pre-process codes or create build scripts with a config file and it seems very difficult to handle a complex task. Grunt ：您可以为开发环境创建自动化功能，以预处理代码或使用配置文件创建构建脚本，这似乎很难处理复杂的任务。 Popular in last few years. 在最近几年流行。

Every task in Grunt is an array of different plugin configurations, that simply get executed one after another, in a strictly independent, and sequential fashion. Grunt中的每个任务都是一系列不同的插件配置，这些插件配置以严格独立且顺序的方式一个接一个地执行。

grunt.initConfig({
  clean: {
    src: ['build/app.js', 'build/vendor.js']
  },

  copy: {
    files: [{
      src: 'build/app.js',
      dest: 'build/dist/app.js'
    }]
  }

  concat: {
    'build/app.js': ['build/vendors.js', 'build/app.js']
  }

  // ... other task configurations ...

});

grunt.registerTask('build', ['clean', 'bower', 'browserify', 'concat', 'copy']);

Gulp : Automation just like Grunt but instead of configurations, you can write JavaScript with streams like it's a node application. Gulp ：自动化与Grunt一样，但是除了配置之外，您还可以像节点应用程序一样使用流编写JavaScript 。 Prefer these days. 这些天比较喜欢。

This is a Gulp sample task declaration. 这是一个Gulp示例任务声明。

//import the necessary gulp plugins
var gulp = require('gulp');
var sass = require('gulp-sass');
var minifyCss = require('gulp-minify-css');
var rename = require('gulp-rename');

//declare the task
gulp.task('sass', function(done) {
  gulp.src('./scss/ionic.app.scss')
    .pipe(sass())
    .pipe(gulp.dest('./www/css/'))
    .pipe(minifyCss({
      keepSpecialComments: 0
    }))
    .pipe(rename({ extname: '.min.css' }))
    .pipe(gulp.dest('./www/css/'))
    .on('end', done);
});

See more: https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4#.fte0nahri 查看更多： https : //medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4#.fte0nahri

4. Scaffolding tools 4.脚手架工具

Slush and Yeoman : You can create starter projects with them. Slush and Yeoman ：您可以使用它们创建启动项目。 For example, you are planning to build a prototype with HTML and SCSS, then instead of manually create some folder like scss, css, img, fonts. 例如，您计划使用HTML和SCSS构建原型，而不是手动创建一些文件夹，如scss，css，img，字体。 You can just install yeoman and run a simple script. 您可以只安装yeoman并运行一个简单的脚本。 Then everything here for you. 然后一切都在这里为您服务。

Find more here . 在这里找到更多。

npm install -g yo
npm install --global generator-h5bp
yo h5bp

See more: https://www.quora.com/What-are-the-differences-between-NPM-Bower-Grunt-Gulp-Webpack-Browserify-Slush-Yeoman-and-Express 查看更多： https : //www.quora.com/What-are-the-differences-between-NPM-Bower-Grunt-Gulp-Webpack-Browserify-Slush-Yeoman-and-Express

My answer is not really matched with the content of the question but when I'm searching for these knowledge on Google, I always see the question on top so that I decided to answer it in summary. 我的答案与问题的内容并不完全匹配，但是当我在Google上搜索这些知识时，我总是会在顶部看到该问题，因此我决定对它进行总结。 Hope you guys found it helpful. 希望你们觉得对您有帮助。

#6楼

Yarn is a recent package manager that probably deserves to be mentioned. Yarn是最近的软件包管理器，可能值得一提。 So, there : https://yarnpkg.com/ 因此，那里： https : //yarnpkg.com/

Afaik, it can fetch both npm and bower dependencies and has other appreciated features. Afaik，它可以获取npm和bower依赖关系，并具有其他令人赞赏的功能。

xfxf996

发布了0 篇原创文章 · 获赞 136 · 访问量 83万+

私信关注