Using Visual Studio Code, Node.js and gulp.js to create a web application - Moving files around

The gulp tasks that form the basis of the entire script

Before I do too much more, I want to setup my build script / project to allow me to (a) make sure that everything in the .dev folder is kept apart from the app folder and set myself up so that I can pull in dependencies via packages so that they're easily updatable and not slowly bloating my repository.

Other parts of this series

Building out the gulp script

Aside: Why not pre-existing build scripts, or a tool like Yeoman? Put simply, I'm using this as an opportunity to work my way round gulp. I've seen scripts and projects that have used tools to produce the build scripts, and that's a great way to have the heavy lifting done for you. If you're starting a new project, using tooling to do the heavy lifting is absolutely the right approach.

[06:43:06] Using gulpfile D:\Git\PreferenceCenter\gulpfile.js
[06:43:06] Starting 'default'...
[06:43:06] Starting 'build'...
[06:43:06] Starting 'build:init'...
[06:43:06] Finished 'build:init' after 1.54 ms
[06:43:06] Starting 'build:copyangular'...
[06:43:06] Finished 'build:copyangular' after 24 ms
[06:43:06] Starting 'build:copyapp'...
[06:43:06] Finished 'build:copyapp' after 5.38 ms
[06:43:06] Finished 'build' after 38 ms
[06:43:06] Starting 'serve'...
[06:43:06] [debugger] client is running
[06:43:06] [debugger] server is running 1.4.0-beta.1
[06:43:06] gulp-server-io (1.4.0-beta.1) running at https://localhost:8000
Starting WebSocket Server
[06:43:06] [Watcher] D:\Git\PreferenceCenter\.dev
[06:43:06] Finished 'serve' after 285 ms
[06:43:06] Finished 'default' after 332 ms
Reload client connected to server

That's the result of running the gulp script now I've made some tweaks to it. Next up is the content of the revised script and then a breakdown of what each section does, and why. So, here's the gulp script as it is right now:

const gulp = require('gulp');
const gulpServerIo = require('gulp-server-io');

var config = 
    "appDestination": ""

gulp.task('serve', () => {
    return gulp.src('./.dev')
            return gulpServerIo();

gulp.task('build:copyangular', (done) => {
        .pipe(gulp.dest(config.appDestination + '/scripts/angularjs/'));

    return done();

gulp.task('build:copyapp', (done) > >

        return done();

gulp.task('dev:init', (done) => {
    config.appDestination = 'app';
    return done();

gulp.task('build:init', (done) => {
    config.appDestination = '.dev';
    return done();

gulp.task('dev', gulp.series('dev:init', 'build:copyangular'));
gulp.task('build', gulp.series('build:init', 'build:copyangular', 'build:copyapp'));
gulp.task('default', gulp.series('build', 'serve'));

Unlike telling a story, the wrong place to start is the beginning. The first change that's worth talking through is the last three lines of the script. Instead of having a default task which passes straight through to the serve task, this now calls build and then serve. This is because of one key, small, change that's been made to the serve task, instead of serving content from the /app folder, it now serves content from the /.dev folder. But, there's not a folder called /.dev? That's because it's not part of the source for the project, it's where I want the files that have been processed by gulp to be placed ready for gulp-server-io to serve up for me. 

Note: The gulp script doesn't currently create the folder, nor does it cope well if the folder isn't present, so make sure that you've created the folder before you run the script. I've left this out to keep the script simple, though I'm sure someone who knows more will point out tht there's an option to set somewhere, or a different syntax that'll result in the folder being created automatically!

The 'build:' tasks

The new build task that's triggered before serve is actually only responsible for calling three other tasks, build:init, build:copyangular and build:copyapp. Not one of these contains anything particularly complicated, interesting or exciting so I'll keep the explanation of each of them fairly brief. In the interests of keeping it simple they could be simplified into one task, but that would make the dev task (which I'll talk about a little later) harder to implement and it'd also end up containing some duplicated code.

build:init - This task, along with its peer dev:init is responsible for setting some values that are used by other parts of the build script. This is basically to allow some of the other tasks to be re-used in different execution flows by, so far, specifying where files should be copied to.

build:copyangular - I've added AngularJs to the project, with the intention of using it later on, by updating package.json to add a dependency and then running npm install:

    "name": "preference-center",
    "version": "1.0.0",
    "private": true,
    "devDependencies": {
        "gulp": "^4.0.0",
        "gulp-server-io": "^1.4.0-beta.1"
    "dependencies": {
        "angular": "^1.6.9"

Even though it's been added as a dependency and the package retrieved, the script files aren't (a) available in the /app folder to be used by editor intellisense, or (b) going to end up in the /.dev folder so that they can be served when the project is being viewed in a browser. This task takes care of that by pulling the files from the node_modules/angular folder and dropping them into the location I want. In the case of build:copyangular this is somewhere below the /.dev folder ready for use by the browser.

build:copyapp - Now the prior two tasks have run which means that the script knows where to deposit files, this task can run to pull the application code from the /app folder and deposit it in the /.dev folder ready to be served.

What next?

I didn't describe the dev task, but it's really there as a convenience. All it does is uses the build:copyangular task to pull AngularJs in and allow it to be referenced during development. Next up will be pulling in a couple of npm packages like ng-annotate and seeing how they interact with gulp build scripts!

About Rob

I've been interested in computing since the day my Dad purchased his first business PC (an Amstrad PC 1640 for anyone interested) which introduced me to MS-DOS batch programming and BASIC.

My skillset has matured somewhat since then, which you'll probably see from the posts here. You can read a bit more about me on the about page of the site, or check out some of the other posts on my areas of interest.

No Comments

Add a Comment