Why I give up gulp and grunt, switch to NPM scripts (on)

This article is from my translation of the Infoq Chinese station, the original address is: Http://www.infoq.com/cn/news/2016/02/gulp-grunt-npm-scripts-part1

Cory House is the author of "Building Applications with React and Flux" and "clean code:writing Code for humans", and is also a lecturer on Pluralsight's many courses. He is a vinsolutions software architect who has trained a large number of software developers around the world, primarily in software development practices such as front-end development and clean code. Cory is a Microsoft MVP, Telerik Developer expert and founder of Outlierdeveloper.com. There has been a lot of debate around the gulp, grunt and NPM scripts communities about whether Gulp and grunt need to continue to be used in the project. Some people insist that the front-end building tools such as Gulp and grunt remain indispensable, while others argue that gulp and grunt are completely unnecessary and add a layer of abstraction that can cause many problems. Recently, Cory wrote about his understanding of gulp, grunt and NPM scripts, and that in the current project, we can completely abandon gulp and grunt, using NPM scripts to meet the needs of the project.

As we all know, gulp and grunt are the building tools used by many projects, and they also have very rich plugins. However, I think gulp and grunt are completely unnecessary abstractions, NPM scripts more powerful and easier to use.

I am a fan of gulp. However, in the previous project, Gulpfile unexpectedly has more than 100 lines, but also used a lot of gulp plug-ins. I try to integrate Webpack, Browsersync, unloading, mocha and other tools through gulp, why do you do this? This is because some of the plugin's documentation is simply too inadequate, and some plugins only expose some of the APIs I need. There is a strange bug in one of the plugins, it can only see part of the contents of the file. Another plugin loses color when it prints to the command line.

Of course, these problems can be solved, but when I use these tools directly, all the problems are gone. Recently, I've noticed that there are many open source projects that just use NPM scripts. So I decided to take a second look at my own approach. Do I really need a gulp? The answer is: no need at all. I decided to use only NPM scripts in my new open source project. I only use NPM scripts to build a development environment and build process for a react application. Want to know what this project looks like? Take a look at react Slingshot. Now, compared to gulp, I prefer to use NPM scripts, and here's why.

What happened to Gulp and grunt?

As time goes by, I find that the following 3 core issues exist with the task runner such as Gulp and grunt:

• Dependency on the plugin author
• Frustrating commissioning
• Disjointed documents

Here is a detailed analysis of the above 3 questions.

Issue 1: Dependency on plug-in authors

When using newer or less popular technologies, there may be no plugins at all. When a plugin is available, the plugin may be obsolete. For example, Babel was released 6 ago. Its API varies so much that many gulp plugins are not compatible with the latest version. I was deeply hurt when I was using gulp because the Gulp plugin I needed was not updated. When using gulp or grunt, you have to wait for the plugin maintainer to provide updates or fix them yourself. This will hinder your chances of using the latest version of modern tools. In contrast, when using NPM scripts, I use the tool directly without adding an additional layer of abstraction. This means that when a new version of Mocha, Istanbul, Babel, Webpack, Browserify, etc. is released, I can use the new version right away. There's nothing to beat NPM for the choice:

Figure

As you can see, Gulp has nearly 2,100 plug-ins, Grunt has nearly 5,400, while NPM offers more than 227,000 packages and continues to grow at more than 400 per day.

When using NPM scripts, you no longer have to search for grunt or gulp plugins, just choose from more than 227,000 NPM packages. To be fair, if the required grunt or gulp plugin does not exist, you can of course use NPM packages directly. However, it is no longer possible to use Gulp or grunt for this particular task.

Issue 2: Frustrating debugging

If the integration fails, debugging in Grunt and gulp is a frustrating thing. Because you're dealing with an extra layer of abstraction, there may be more potential causes for any bug:

• is the underlying tool a problem?
• Is there a problem with the Grunt/gulp plugin?
• Did you configure the problem?
• Is the version used is not incompatible?

Using NPM scripts to eliminate the 2nd of the above, I find that the 3rd is rarely seen, because I am usually the command-line interface to invoke the tool directly. Finally, the 4th is rare because I reduce the number of packages in the project by using NPM directly instead of the task runner's abstraction.

Issue 3: Disjointed documents

In general, the document quality of the core tools I need is always better than the grunt and gulp plugins associated with them. For example, if you use Gulp-eslint, then I have to switch back and forth between the Gulp-eslint document and the Eslint site, and I have to switch contexts between the plugin and the tool abstracted by the plugin. The problem with Gulp and grunt is that the tools used to understand the light are far from enough. Gulp and grunt require you to understand the abstraction of plugins.

Most build-related tools provide a clear, powerful, and command-line interface with high-quality documentation. Eslint's CLI documentation is a good example. I find it easier to read and implement a short command-line invocation in NPM scripts, with fewer obstacles and easier debugging (because there is no abstraction layer exists). Now that we know the pain point, the next question is, why do we think we need a task runner like Gulp and grunt?

I believe the reasons for this should vary from person to person. There is no doubt that the task runner such as Gulp and grunt has been around for a long time, and that the plug-in ecosystem surrounding these task-running players has shown a thriving boom. Depending on these plugins, many daily tasks can be automated and run well. In this way, people will think that only through these task runner to achieve the task of building, file packaging, workflow and good running, and so on. Another reason is that people don't know much about NPM scripts, and the things and tasks that NPM scripts can accomplish are also on the surface. This has also led to a lot of people not discovering that NPM scripts can achieve many of the results of the build tasks that are being developed in the day. I believe that with the developer's understanding of NPM scripts, we will gradually discover that using NPM scripts can also accomplish tasks such as Gulp and grunt, and the configuration is simpler and more straightforward. Because it will use the target tool directly without having to use the wrapper for the target tool.

In the next article in this series, let's look at the reasons why NPM scripts is overlooked and what it can do with NPM scripts.

Why I give up gulp and grunt, switch to NPM scripts (on)