Scott Addie

Last Updated: 7/24/2016

Within an older blog post, entitled “Webpackin’ your ES 2015 / Angular 1.x SPA“, I explained how to use npm scripts to execute Webpack commands. To quickly recap, this approach took advantage of custom scripts in the package.json file, as depicted in the gist below.

As an avid Visual Studio (VS) Code user, I found myself yearning for a more seamless means of integrating Webpack with the editor. Why? Truthfully, I had been spoiled by Task Runner Explorer in Visual Studio 2015. Surely Microsoft had pondered how to solve the problem of task management in their latest modern web, cross-platform editor venture. At least that was my expectation. Thankfully, there is a viable alternative to the npm scripts approach which leverages an editor extensibility point for integrating with third-party tools.

The aforementioned extensibility point in VS Code is a JSON-based configuration file known as tasks.json. You can read more about its purpose and uses here. As of VS Code 0.8.0, this file should be placed within a .vscode folder at the project’s root. In versions prior to 0.8.0, the .vscode folder was named .settings. While VS Code lacks a rich item-templating system such as that available in full-blown Visual Studio, it does assist us in creating this file.

To create a new tasks.json file, open Command Palette (via Ctrl + Shift + P on Windows), and type “configure”. The “Tasks: Configure Task Runner” option will appear. Select it, and you’re presented with a list of templates. Select “Others”, and notice that an unassuming configuration file is stubbed out for you. Full IntelliSense is provided via Ctrl + Space to help guide you to the correct solution.

Configuring the Extensibility Point: tasks.json

Below is a sample tasks.json file exhibiting the Webpack integration. It replicates the functionality of the two npm scripts appearing above, verbatim.

Here’s a summary of the crucial properties appearing within the JSON file:

1. command

This property value references the webpack binary stored in the project’s local node_modules folder. It uses a predefined variable in VS Code, called ${workspaceRoot}. This variable expands to the absolute path of the folder which is opened in VS Code. If you come from an MSBuild background, this may remind you of the $(MSBuildProjectDirectory) variable that would be accessed in an AfterBuild target, for example.

2. isShellCommand

When set to true, this property value signals VS Code to execute the associated command in the shell. Change its value to false, and an error such as the following will appear:

running command> c:\working_folder\sample_apps\webpack-angular-es2015/node_modules/.bin/webpack --display-modules --progress -d
Failed to launch external program ${workspaceRoot}/node_modules/.bin/webpack --display-modules --progress.
spawn c:\working_folder\sample_apps\webpack-angular-es2015/node_modules/.bin/webpack ENOENT

3. args

There are a few distinct renditions of this property in our example. The top-level instance, appearing at line 5, contains parameters which will cascade down to all task configurations. In regards to overall maintainability of this configuration file, the top-level instance allows us to keep things DRY. The lower-level instances, appearing at lines 12 and 20, apply to their respective local task configurations. In other words, when executing the webpack dist task, both the top- and the lower-level values will be disbursed to the shell as CLI arguments.

Speaking of CLI arguments, how would one know what’s available in Webpack? The options are documented here. Using this knowledge, one could easily create a new task configuration object literal which makes use of Webpack’s –watch CLI option. Or maybe it makes the most sense to add –watch as a second entry in the args array for the webpack dev task.

4. echoCommand

When set to true, this property value instructs VS Code to print the command-to-be-executed in the console. Did you notice the following line in the console output?

running command> c:\working_folder\sample_apps\webpack-angular-es2015/node_modules/.bin/webpack --display-modules --progress -p

5. tasks

This property’s value is an array of the possible task configurations. Each task configuration is defined as an object literal. In this example, a development and a production-grade build task were defined. The development build task necessitates a “-d” CLI argument, while the production-grade build task requires a “-p” argument. To support this behavior, there is clearly a need for two separate configurations. This is the justification for the two object literals in the tasks array.

6. suppressTaskName

When set to true, this property will prevent the taskName value from being appended to the command executed in the shell. If we were to execute the webpack dist task configuration with this property value set to false, the following command would be sent to the shell for execution:

running command> c:\working_folder\sample_apps\webpack-angular-es2015/node_modules/.bin/webpack --display-modules --progress -p webpack dist

Note the bolded portion of that command. A problem is impending. Consequently, this command will result in an error containing a message similar to:

ERROR in multi main
Module not found: Error: Cannot resolve module 'webpack dist' in c:\working_folder\sample_apps\webpack-angular-es2015/app
@ multi main

7. taskName

This property value represents the alias by which the task configuration is referenced in VS Code. Launch Command Palette, type “task”, select the “Tasks: Run Task” option in the search results, and notice that the names appearing correspond to the taskName property values.

8. isBuildCommand

A build command is invoked using the Ctrl + Shift + B key combination on Windows. Alternatively, selecting the “Tasks: Run Build Task” option from Command Palette accomplishes the same thing. In the tasks.json file provided, the webpack dev task configuration is marked as the default build command. Setting the isBuildCommand property to true for the webpack dist task configuration would have no effect, In fact, the editor will honor only the first occurrence. Order is paramount here.

Running a Webpack Task via Command Palette

Using VS Code’s Command Palette, the task configurations defined within this file’s tasks property can be discovered and launched. Simply choose Command Palette’s “Tasks: Run Task” option. In the following screenshot, note that two task aliases appear after selecting the “Tasks: Run Task” option. These correspond to the taskName property values within tasks.json’s tasks array.

Upon selecting the webpack dist task alias from the drop-down, the task runs, and the following output appears:

As was explained in the isBuildCommand property’s description above, Ctrl + Shift + B is an even more convenient way to launch the default build task.

Conclusion

With VS Code’s robust task integration support, the possibilities are truly endless. Think of all the other tools you’re invoking from the command line today to augment your development workflow. Maybe it’s Grunt, Gulp, MSBuild, ESLint, Babel, or the TypeScript compiler. Now these tools can be invoked without leaving the comfort of the editor. That’s a huge win in terms of developer productivity!

For a deeper dive into VS Code’s task functionality, I highly recommend watching John Papa’s Visual Studio Code course on Pluralsight. In fact, this is where I first learned the inner workings of this feature.