Gulp is accessible in VS Code using the Integrated Terminal, that you can access from View | Integrated Terminal. By typing gulp without any extra parameters, Gulp will run a default task. You can also run gulp from a Command Prompt or PowerShell window.

Tasks are described in a separate configuration file within the project folder called gulpfile.js. It is rather small in the SPFx default project, as a lot of work is done through SPFx tooling (sp-build-web, for example), but it is more than sufficient for your typical needs as a developer:

Line 6 is key here; it runs initialization for gulp as part of the build process. To understand what's going on here, we need to locate @microsoft/sp-build-web, which is one of the packages we installed earlier. By initializing the package, we automatically import and configure the necessary build tasks for a web browser-based (SharePoint Workbench in this case) build target.

To see what we can do with Gulp in a SharePoint Framework project, we need to peek at a file called package.json, which is also in the same directory as the project. This file describes our project, project dependencies, and also the Gulp tasks that are equivalent to our project tasks:

As we can see, we have the following Gulp tasks pre-configured for us:

• bundle: Bundles the entry point client-side file, and the required dependent files to a single JavaScript file.
• clean: Cleans up build files left over from previous builds
• test: Runs all tests against the current project

But why is it that we do not have gulp serve here, as that is something we've been using to run our projects? The reason lies in another package, the @microsoft/sp-build-core-tasks, that is being referenced as a Node.js module. This lists the following additional tasks for Gulp:

• build: Builds the project
• serve: Runs SharePoint Workbench locally
• nuke: Cleans everything within the project, including build artifacts, and build target directories
• package-solution: Packages the solution to a SharePoint package
• deploy-azure-storage: Deploys assets to Microsoft Azure-hosted storage

To find all Gulp tasks, you can run gulp --tasks.

As is evident, Gulp as a tool is critical but, at the same time, it's quite simplistic to use. Besides gulp serve, you will be using gulp package-solution quite a bit when you choose to test your code in a real SharePoint environment tenant outside SharePoint Workbench.

To package a project for our next phase, we'll start with gulp bundle to put everything together first. We can append the --ship parameter to create a mini version of all assets, essentially optimizing the solution:

This produces the minified files, with localization support under /temp/deploy of our project folder structure:

Next, we need to produce a deployment package with gulp package-solution:

This will create a file with the .sppkg extension, that is a package SharePoint Framework project. It is stored under a sub-directory of the project folder at /sharepoint/solution:

If we take a copy of the .sppkg file and rename the copy with the new file extension .zip, we can easily open the compiled package to reveal its content:

It looks very similar to a SharePoint add-in package, with a special AppManifest.xml file to instruct SharePoint what to do upon installation. In order to view the XML-file in VS Code, we can simply open the file, but for easier reading, we need an extension that helps us to format the XML properly. One such would be XML Tools:

Now we can open AppManifest.xml to reveal its logic:

This is a client-side solution, as all SharePoint Framework solutions are, and it also requires at least version 16.0.0.0 for SharePoint. In the package, we also have a separate XML for individual SharePoint Features, which act as the provisioning engine for SharePoint Framework-based web parts. These are identical to classic SharePoint Feature Framework-type customizations but they are now autogenerated for us.

Now that we have a package, we can clean up the temporary files from the previous build by running gulp clean.

Next, we'll actually deploy the package to SharePoint.