gulp 和npm

I know what you’re thinking. WAT?! Didn’t Gulp just kill Grunt? Why can’t we just be content for a few minutes here in JavaScript land? I hear ya, but…

我知道你在想什么 WAT ？！ 古爾普不是殺死了咕unt嗎？ 為什么我們不能只在JavaScript領域呆上幾分鐘呢？ 我聽到了，但是…

I’ve found Gulp and Grunt to be unnecessary abstractions. npm scripts are plenty powerful and often easier to live with.

我發現Gulp和Grunt是不必要的抽象。 npm腳本功能強大，通常更易于使用。

讓我們從一個例子開始... (Let’s Begin With An Example…)

I was a big fan of Gulp. But on my last project, I ended up with 100’s of lines in my gulpfile and around a dozen Gulp plugins. I was struggling to integrate Webpack, Browsersync, hot reloading, Mocha and much more using Gulp. Why? Well, some plugins had insufficient documentation for my use case. Some plugins only exposed part of the API I needed. One had an odd bug where it would only watch a small number of files. Another stripped colors when outputting to the command line.

我是Gulp的忠實粉絲。 但是在我的上一個項目中，我最終在gulpfile中添加了100行代碼，并使用了大約12個Gulp插件。 我正在努力使用Gulp集成Webpack，Browsersync，熱重裝，Mocha以及更多功能。 為什么？ 好吧，有些插件沒有針對我的用例的文檔。 一些插件僅公開了我需要的API的一部分。 一個人有一個奇怪的錯誤，即它只能觀看少量文件。 當輸出到命令行時，另一種顏色被剝離。

These are solvable problems, but none of these issues occurred when I called the tools directly.

這些是可解決的問題，但是當我直接調用工具時，這些問題都沒有發生。

Lately I’ve noticed many open-source projects are simply using npm scripts. I decided to step back and re-examine. Did I really need Gulp? It turns out I didn’t.

最近，我注意到許多開源項目都只是使用npm腳本。 我決定退后一步，重新檢查。 我真的需要Gulp嗎？ 原來我沒有。

I decided to try using just npm scripts on my new open source project. I created a rich dev environment and build process for React applications using just npm scripts. Curious what this looks like? Check out React Slingshot. I walk through how to create this build process using npm scripts in “Building a JavaScript Development Environment” on Pluralsight.

我決定嘗試在新的開源項目中僅使用npm腳本。 我僅使用npm腳本創建了一個豐富的開發環境并為React應用程序構建過程。 好奇這是什么樣子？ 查看React Slingshot 。 我將在Pluralsight上的“ 構建JavaScript開發環境 ”中逐步介紹如何使用npm腳本創建此構建過程。

The surprising thing is, I now prefer working with npm scripts over Gulp. Here’s why.

令人驚訝的是，與Gulp相比，我現在更喜歡使用npm腳本。 這就是為什么。

Gulp和Grunt有什么問題？ (What’s Wrong with Gulp and Grunt?)

Over time, I’ve noticed three core issues with task runners like Gulp and Grunt:

隨著時間的流逝，我已經注意到任務執行者(例如Gulp和Grunt)的三個核心問題：

1. Dependence on plugin authors
   對插件作者的依賴
2. Frustrating debugging
   令人沮喪的調試
3. Disjointed documentation
   脫節的文件

Let’s consider each of these issues.

讓我們考慮所有這些問題。

問題1：對插件作者的依賴 (Issue 1: Dependence on Plugin Authors)

When you’re working with new or unpopular technologies, no plugin may exist at all. And when a plugin exists, it may be outdated. For example, Babel 6 was recently released. The API changed significantly, so many Gulp plugins were incompatible with the latest version. When using Gulp, I was stuck because the Gulp plugin I needed wasn’t updated yet.

當您使用新技術或不受歡迎的技術時，可能根本不存在任何插件。 并且當插件存在時，它可能已過時。 例如，Babel 6是最近發布的。 API發生了重大變化，因此許多Gulp插件與最新版本不兼容。 使用Gulp時，我陷入了困境，因為所需的Gulp插件尚未更新。

With Gulp or Grunt, you must wait for plugin maintainers to provide updates, or fix it yourself. This delays your ability to utilize new versions of modern tools. In contrast, when I use npm scripts, I consume tools directly without an extra layer of abstraction. This means when new versions of Mocha, Istanbul, Babel, Webpack, Browserify and so on are released, I’m able to utilize the new versions immediately.

使用Gulp或Grunt，您必須等待插件維護者提供更新或自行修復。 這會延遲您使用現代工具的新版本的能力。 相反， 當我使用npm腳本時，無需使用額外的抽象層即可直接使用工具 。 這意味著當發布新版本的Mocha，Istanbul，Babel，Webpack，Browserify等時，我能夠立即使用這些新版本。

In terms of selection, nothing beats npm:

在選擇方面，npm勝過一切：

When you use npm scripts, you don’t search for a Grunt or Gulp plugin. You choose from over 227,000 npm packages.

使用npm腳本時，無需搜索Grunt或Gulp插件。 您可以從超過227,000個npm軟件包中進行選擇。

To be fair, if the Grunt or Gulp plugin you need isn’t available, you can certainly utilize npm packages directly. But then you’re no longer leveraging Gulp or Grunt for that specific task.

公平地說，如果您需要的Grunt或Gulp插件不可用，您當然可以直接使用npm軟件包。 但是，您不再需要利用Gulp或Grunt來完成特定任務。

問題2：令人沮喪的調試 (Issue 2: Frustrating Debugging)

As integrations fail, debugging in Grunt and Gulp can be frustrating. Since you’re working with an extra layer of abstraction, there are more potential causes for any bug:

由于集成失敗，在Grunt和Gulp中進行調試可能會令人沮喪。 由于您正在使用額外的抽象層，因此，存在更多可能導致任何錯誤的原因：

1. Is the base tool broken?
   基本工具是否損壞？
2. Is the Grunt/Gulp plugin broken?
   Grunt / Gulp插件是否損壞？
3. Is my configuration broken?
   我的配置壞了嗎？
4. Am I using incompatible versions?
   我使用的版本不兼容嗎？

Using npm scripts eliminates #2. And I find #3 is far less common since I typically call the tool’s command line interface directly. Finally, #4 is less common since I’ve reduced the number of packages in my project by utilizing npm directly instead of using a task runner’s abstraction.

使用npm腳本消除了＃2。 而且我發現＃3不太常見，因為我通常直接調用該工具的命令行界面。 最后，＃4不太常見，因為我通過直接利用npm而不是使用任務運行程序的抽象來減少項目中的軟件包數量。

問題3：脫節的文檔 (Issue 3: Disjointed Documentation)

The documentation for the core tools I need is nearly always better than the associated Grunt and Gulp plugins. For example, if I use gulp-eslint, I end up splitting my time between the gulp-eslint docs and the ESLint website. I have to switch context between the plugin and the tool it is abstracting. The core piece of friction in Gulp and Grunt is this:

我所需的核心工具的文檔幾乎總是比相關的Grunt和Gulp插件更好。 例如，如果我使用gulp-eslint，最終我會在gulp-eslint文檔和ESLint網站之間分配時間。 我必須在插件和正在抽象的工具之間切換上下文。 Gulp和Grunt的核心摩擦是：

Understanding the tool isn’t enough. Gulp and Grunt require you to understand the plugin’s abstraction.

僅僅了解該工具還不夠。 Gulp和Grunt要求您了解插件的抽象。

Most build-related tools offer clear, powerful, and well-documented command line interfaces. See the docs on ESLint’s CLI as a good example. I find reading and implementing a short command line call in npm scripts clearer, lower friction, and easier to debug (since there’s a layer of abstraction removed).

大多數與構建相關的工具都提供清晰，功能強大且有據可查的命令行界面。 請參閱ESLint CLI上的文檔作為一個很好的示例。 我發現在npm腳本中閱讀和實現簡短的命令行調用更加清晰，摩擦更少，更易于調試(因為已刪除了抽象層)。

Now that I’ve established the pain points, the question is, why do we think we need task runners like Gulp and Grunt?

現在，我已經確定了痛點，問題是，為什么我們認為我們需要像Gulp和Grunt這樣的任務賽跑者？

為什么我們忽略了npm的構建？ (Why Have We Ignored npm for builds?)

I believe there are four core misconceptions that led to Gulp and Grunt becoming so popular:

我相信有四個核心誤解導致Gulp和Grunt如此流行：

1. People think npm scripts require strong command line skills
   人們認為npm腳本需要強大的命令行技能
2. People think npm scripts aren’t powerful enough
   人們認為npm腳本不夠強大
3. People think Gulp’s streams are necessary for fast builds
   人們認為Gulp的流對于快速構建是必要的
4. People think npm scripts don’t run cross platform
   人們認為npm腳本不能跨平臺運行

Let’s address these misconceptions in order.

讓我們按順序解決這些誤解。

誤解1 ： npm腳本需要強大的命令行技能 (Misconception 1: npm Scripts Require Strong Command-Line Skills)

You don’t have to know much about your operating system’s command line to enjoy the power of npm scripts. Sure, grep, sed, awk, and pipes are lifelong skills worth learning, but you don’t have to be a Unix or Windows command line wizard to use npm scripts. You can leverage the 1000’s of packages in npm to get the job done instead.

您無需對操作系統的命令行了解太多，就可以享受npm腳本的強大功能。 當然， grep，sed，awk和管道是一生值得學習的技能，但是您不必是Unix或Windows命令行向導即可使用npm腳本 。 您可以在npm中利用1000個軟件包來完成工作。

For instance, you might not know that in Unix this forcefully deletes a directory: rm -rf. That’s okay. You can use rimraf which does the same thing (and it works cross-platform to boot). Most npm packages offer interfaces that assume very little knowledge of your OS’s command line. Just search npm for packages that do what you need, read the docs, learn as you go. I used to search for Gulp plugins. Now I search for npm packages instead. A great resource: libraries.io.

例如，您可能不知道在Unix中這會強制刪除目錄：rm -rf。 沒關系。 您可以使用rimraf來做同樣的事情(它可以跨平臺啟動)。 大多數npm軟件包提供的界面假定您對操作系統的命令行了解很少。 只需在npm中搜索可以滿足您需求的軟件包，閱讀文檔，邊走邊學。 我曾經搜索Gulp插件。 現在，我搜索npm軟件包。 很棒的資源： libraries.io 。

誤解2：npm腳本不夠強大 (Misconception #2: npm Scripts Aren’t Powerful Enough)

npm scripts are surprisingly powerful on their own. There are convention-based pre and post hooks:

npm腳本本身具有強大的功能。 有基于約定的pre和post掛鉤 ：

{"name": "npm-scripts-example","version": "1.0.0","description": "npm scripts example","scripts": {"prebuild": "echo I run before the build script","build": "cross-env NODE_ENV=production webpack","postbuild": "echo I run after the build script"}
}

All you do is follow convention. The scripts above will run in order based on their prefix. The prebuild script will run before the build script because it has the same name, but is prefixed with “pre”. The postbuild script will run after the build script because it has the prefix of “post”. So if I create scripts named prebuild, build, and postbuild, they’ll run automatically in that order when I type `npm run build`.

您要做的就是遵循慣例。 上面的腳本將根據其前綴按順序運行。 預構建腳本將在構建腳本之前運行，因為它具有相同的名稱，但前綴為“ pre”。 postbuild腳本將在構建腳本之后運行，因為它的前綴為“ post”。 因此，如果我創建名為prebuild，build和postbuild的腳本，那么當我輸入`npm run build`時，它們將按照該順序自動運行。

You can also decompose big problems by calling one script from another:

您還可以通過從另一個腳本中調用一個腳本來分解大問題：

{"name": "npm-scripts-example","version": "1.0.0","description": "npm scripts example","scripts": {"clean": "rimraf ./dist && mkdir dist","prebuild": "npm run clean","build": "cross-env NODE_ENV=production webpack"}
}

In this example the prebuild task calls the clean task. This allows you to decompose your scripts into small, well-named, single responsibility, one-liners.

在此示例中，預構建任務將調用clean任務。 這使您可以將腳本分解為名稱明確的單一職責的一小部分代碼。

You can call multiple scripts serially on a single line using &&. The scripts in the clean step above will run one after the other. This simplicity will really make you smile if you’re someone who has struggled with getting a list of tasks to run in order in Gulp.

您可以使用&&在一行上依次調用多個腳本。 上面干凈步驟中的腳本將一個接一個地運行。 如果您一直在努力讓任務列表按順序在Gulp中運行，那么這種簡單性將使您微笑。

And if a command gets too complicated, you can always call a separate file:

而且，如果命令變得太復雜，則始終可以調用一個單獨的文件：

{"name": "npm-scripts-example","version": "1.0.0","description": "npm scripts example","scripts": {"build": "node build.js"}
}

I’m calling a separate script in the build task above. That script will be run by Node and thus can utilize any npm packages I need, and utilize all the power of JavaScript inside.

我在上面的構建任務中調用了一個單獨的腳本。 該腳本將由Node運行，因此可以利用我需要的任何npm軟件包，并利用內部JavaScript的所有功能。

I could go on, but the core features are documented here. Also, there’s also a short Pluralsight course on using npm as a build tool. Or, check out React Slingshot for an example of all this in action.

我可以繼續，但是這里記錄了核心功能 。 另外，還將有一個簡短的Pluralsight課程，介紹如何使用npm作為構建工具 。 或者，查看React Slingshot以獲取所有這些示例的示例。

誤解3：快速構建需要Gulp的流 (Misconception 3: Gulp’s Streams Are Necessary for Fast Builds)

Gulp quickly gained traction over Grunt because Gulp’s in-memory streams are faster than Grunt’s file-based approach. But you don’t need Gulp to enjoy the power of streaming. In fact, streaming has always been built into both Unix and Windows command lines. The pipe (|) operator streams the output of one command to the input of another command. And the redirection (>) operator redirects output to a file.

Gulp很快就吸引了Grunt，因為Gulp的內存中流比Grunt的基于文件的方法要快。 但是您不需要Gulp來享受流媒體的力量。 實際上， 流傳輸始終內置在Unix和Windows命令行中 。 管道(|)運算符將一個命令的輸出流式傳輸到另一命令的輸入。 重定向(>)運算符會將輸出重定向到文件。

So, for example, in Unix I can use `grep` the contents of a file and redirect the output to a new file:

因此，例如，在Unix中，我可以使用`grep`文件的內容并將輸出重定向到新文件：

grep ‘Cory House’ bigFile.txt > linesThatHaveMyName.txt

The work above is streamed. No intermediate files are written. (Wondering how to do the command above in a cross-platform way? Read on…)

以上工作已流式傳輸。 沒有寫入中間文件。 (想知道如何以跨平臺方式執行上面的命令嗎？請繼續閱讀...)

You can also use the `&` operator to run two commands at the same time on Unix:

您也可以在Unix上使用`＆`運算符同時運行兩個命令：

npm run script1.js & npm run script2.js

The two scripts above will run in at the same time. To run scripts concurrently cross platform, use npm-run-all. This leads to the next misconception…

上面的兩個腳本將同時運行。 要跨平臺同時運行腳本，請使用npm-run-all 。 這導致了下一個誤解……

誤解4：npm腳本不能跨平臺運行 (Misconception 4: npm Scripts Don’t Run Cross-platform)

Many projects are tied to a specific operating system, so cross-platform concerns don’t matter. But if you need to run cross-platform, npm scripts can still work great. Countless open source projects are proof. Here’s how.

許多項目都與特定的操作系統相關聯，因此跨平臺的關注無關緊要。 但是，如果您需要運行跨平臺，npm腳本仍然可以很好地工作。 無數開源項目就是證明。 這是如何做。

Your operating system’s command line runs your npm scripts. So on Linux and OSX, your npm scripts run on a Unix command line. On Windows, npm scripts run on the Windows command line. Thus, if you want your build scripts to run on all platforms, you need to make both Unix and Windows happy. Here are three approaches:

操作系統的命令行運行npm腳本。 因此，在Linux和OSX上，您的npm腳本在Unix命令行上運行。 在Windows上，npm腳本在Windows命令行上運行。 因此，如果要使構建腳本在所有平臺上運行，則需要使Unix和Windows都滿意。 這是三種方法：

Approach 1: Use commands that run cross-platform. There’s a surprising number of cross-platform commands. Here’s a few:

方法1：使用跨平臺運行的命令 。 跨平臺命令數量驚人。 這里有一些：

&& chain tasks (Run one task after another)
< input file contents to a command
> redirect command output to a file
| redirect command output to another command

Approach 2: Use node packages. You can use node packages instead of shell commands. For instance, use rimraf instead of `rm -rf`. Use cross-env to set environment variables in a cross-platform way. Search Google, npm or libraries.io for what you want to do and there is almost certainly a node package that will get it done cross-platform. And if your command line calls get too long, you can call Node packages in separate scripts as well like this:

方法2：使用節點包。 您可以使用節點包而不是shell命令。 例如，使用rimraf而不是`rm -rf`。 使用cross-env以跨平臺的方式設置環境變量。 在Google，npm或libraries.io中搜索您想做什么，幾乎可以肯定有一個節點程序包可以跨平臺完成它。 而且，如果您的命令行調用太長，則可以在單獨的腳本中調用Node程序包，如下所示：

node scriptName.js

The script above is plain old JavaScript, run by Node. And since you’re just calling a script on the command line, you’re not limited to .js files. You can run any script that your OS can execute such as Bash, Python, Ruby, or Powershell as well.

上面的腳本是由Node運行的普通JavaScript。 而且，由于您只是在命令行上調用腳本，因此您不僅限于.js文件。 您也可以運行OS可以執行的任何腳本，例如Bash，Python，Ruby或Powershell。

Approach 3: Use ShellJS. ShellJS is an npm package that runs Unix commands via Node. So this gives you the power to run Unix commands on all platforms, including Windows.

方法3 ：使用ShellJS 。 ShellJS是一個npm軟件包，可通過Node運行Unix命令。 因此，這使您能夠在包括Windows在內的所有平臺上運行Unix命令。

I used a combination of approach #1 and #2 on React Slingshot.

我在React Slingshot上結合了方法1和方法2。

痛點 (Pain Point)

There are admittedly some downsides: The JSON spec doesn’t support comments, so you can’t add comments in package.json. There are a few ways to work around this limitation:

誠然有一些缺點：JSON規范不支持注釋，因此您不能在package.json中添加注釋。 有幾種方法可以解決此限制：

1. Write small, well-named, single purpose scripts
   編寫小型的，名字明確的，單一目的的腳本
2. Document scripts separately (in a README.md for instance)
   單獨編寫文檔腳本(例如在README.md中)
3. Call a separate .js file
   調用一個單獨的.js文件

I prefer option #1. If you break each script down to have a single responsibility, comments are rarely necessary. The script’s name should fully describe the intent, just like any small well-named function. As I discuss in “Clean Code: Writing Code for Humans”, small single responsibility functions rarely require comments. When I feel a comment is necessary, I use option #3 and move the script to a separate file. This gives me all the compositional power of JavaScript when I need it.

我更喜歡選擇＃1。 如果將每個腳本分解為一個職責，則很少需要注釋。 腳本的名稱應充分描述其意圖，就像任何小的命名函數一樣。 正如我在“ 簡潔代碼：編寫人類代碼 ”中所討論的那樣，小的單一職責功能很少需要注釋。 當我覺得有必要發表評論時，我使用選項＃3并將腳本移到單獨的文件中。 這在需要時為我提供了JavaScript的全部組合功能。

Package.json also doesn’t support variables. This sounds like a big deal, but it’s not for two reasons. First, the most common need for variables revolves around environment, which you can set on the command line. Second, if you need variables for other reasons, you can call a separate .js file. Check out React-starter-kit for an elegant example of this pattern.

Package.json也不支持變量。 這聽起來很重要，但這并不是出于兩個原因。 首先，最常見的變量需求圍繞環境，您可以在命令行上進行設置。 其次，如果由于其他原因需要變量，則可以調用一個單獨的.js文件。 查看React-starter-kit以獲得該模式的優雅示例。

Finally, there’s also a risk of creating long, complex command line arguments that are difficult to understand. Code reviews and diligent refactoring are a great way to assure npm scripts are decomposed into small, well-named, single purpose functions that everyone understands. If it’s complex enough to need a comment, you should likely refactor the single script into multiple well named scripts or extract it to a separate file.

最后，還有創建難以理解的長而復雜的命令行參數的風險。 代碼審查和勤奮的重構是確保npm腳本被分解為每個人都可以理解的小型，有名字的，單一目的的功能的好方法。 如果復雜到需要注釋的程度，您應該將單個腳本重構為多個命名良好的腳本，或者將其提取到單獨的文件中。

抽象必須合理 (Abstractions Must Be Justified)

Gulp and Grunt are abstractions over the tools I use. Abstractions are useful, but abstractions have a cost. They leak. They make us dependent upon the plugin maintainers and their documentation. And they add complexity by increasing the number of dependencies. I’ve decided task runners like Gulp and Grunt are abstractions I no longer need.

Gulp和Grunt是我使用的工具的抽象。 抽象是有用的，但是抽象是有代價的。 他們泄漏。 它們使我們依賴于插件維護者及其文檔。 并且它們通過增加依賴性數量而增加了復雜性。 我已經確定像Gulp和Grunt這樣的任務運行者是我不再需要的抽象。

Looking for details? I walk through how to create a build process using npm scripts from scratch in “Building a JavaScript Development Environment” on Pluralsight.

尋找細節？ 我將在Pluralsight上的“ 構建JavaScript開發環境 ”中逐步介紹如何使用npm腳本創建構建過程。

Comments? Chime in below or on Reddit or Hacker News.

注釋？ 在Reddit或Hacker News下方或上方發出提示音 。

Finally, I’m far from the first person to suggest this. Here are some excellent links:

最后，我離提出這個建議的第一個人還很遠。 這里有一些很好的鏈接：

• Task automation with npm run — James Holliday

  使用npm run實現任務自動化 — James Holliday

• Advanced front-end automation with npm scripts — Kate Hudson

  帶有npm腳本的高級前端自動化 — Kate Hudson

• How to use npm as a build tool — Kieth Cirkel

  如何使用npm作為構建工具 — Kieth Cirkel

• Introduction to npm as a Build Tool — Marcus Hammarberg

  npm作為構建工具簡介 — Marcus Hammarberg

• Gulp is awesome, but do we really need it? — Gonto

  Gulp很棒，但是我們真的需要嗎？ —貢托

• NPM Scripts for Build Tooling — Andrew Burgess

  用于構建工具的NPM腳本-Andrew Burgess

Cory House is the author of “React and Redux in ES6”, “Clean Code: Writing Code for Humans” and multiple other courses on Pluralsight. He is a Software Architect at VinSolutions and trains software developers internationally on software practices like front-end development and clean coding. Cory is a Microsoft MVP, Telerik Developer Expert, and founder of outlierdeveloper.com.

Cory House是“ ES6中的React和Redux ”，“ 純凈代碼：人類編寫代碼 ”以及其他有關Pluralsight的課程的作者 。 他是VinSolutions的軟件架構師，并就前端開發和干凈編碼等軟件實踐對國際軟件開發人員進行培訓 。 Cory是Microsoft MVP，Telerik開發專家和outlierdeveloper.com的創始人。

翻譯自: https://www.freecodecamp.org/news/why-i-left-gulp-and-grunt-for-npm-scripts-3d6853dd22b8/

gulp 和npm