npmgulpgulp-4

Why is this gulp script behaving differently between v4.0.0-alpha.2 and v4.0.2?

Whilst this script is using gulp 4.0.0-alpha.2, I suspect that the script was originally written for 3.x.

I have a gulp script that I inherited which has the following task present:

pump([
    gulp.src(['app\\images\\**\\*.*']),
    gulp.dest('.dev\\images')
] , done);

(The values passed into .src and .dest were originally retrieved from elsewhere but there doesn't appear to be any code that modifies them)

The app\images folder contains an icons sub-folder which contains multiple files, the result of the gulp script is:

It appears that the two full paths get concatenated now, whereas previously only the relative paths from the glob (i.e. when app\images\**\*.* found app\images\icons\icon1.png it returned icons\icon1.png).

Passing base into the options when calling src appears to resolve this:

pump([
    gulp.src(['app\\images\\**\\*.*'], { base: 'app\\images\\' }),
    gulp.dest('.dev\\images\\')
] , done);

This doesn't solve cases where an array of paths with disparate base paths is passed, e.g:

['app\\styles\brand\**\*.*', 'app\\brands\icons\icons.data.svg.css']

It also seems likely that there's a more generic solution available that doesn't require me to update every invocation of src, so....

How can I obtain the same behaviour using Gulp 4.0, where only the glob onwards, or the name of the file is used when writing to the destination?

Minimal repro gulpfile.js:

'use strict';
const gulp = require('gulp');

exports.build = function()
{
    return gulp.src(['app\\images\\**\\*.*'])
        .pipe(gulp.dest('.dev\\images'));
}

And package.json:

{
  "name": "test-web",
  "version": "1.0.0",
  "description": "Test Project",
  "main": "gulpfile.js",
  "scripts": {
    "build": "gulp build"
  },
  "author": "Me",
  "license": "ISC",
  "devDependencies": {
    "gulp": "^4.0.2"
  }
}

There are files under app\images\android and app\images\apple (2 in each)

Result with gulp@4.0.0-alpha.2 (expected/desired):

Result with gulp@v4.0.2 (un-expected):

Solution

  • From path separators in globs, gulpjs docs:

    Segments and separators

    A segment is everything between separators. The separator in a glob is always the / character - regardless of the operating system - even in Windows where the path separator is \\. In a glob, \\ is reserved as the escape character.

    And from the glob docs: Windows paths:

    Please only use forward-slashes in glob expressions.

    Though windows uses either / or \ as its path separator, only / characters are used by this glob implementation. You must use forward-slashes only in glob expressions. Back-slashes will always be interpreted as escape characters, not path separators.

    So your glob ['app\\images\\**\\*.*' is definitely a problem as it has escape sequences rather than the required / path separators.

    In particular, glob (or gulp) is not able to figure out the base with all the escape sequences in there. When you explicitly set the base apparently that fixes the problem.

    It isn't clear to me why your glob actually finds anything, perhaps because of this:

    If an escaped pattern has no matches, and the nonull flag is set, then glob returns the pattern as-provided, rather than interpreting the character escapes.

    From glob docs. The nonull flag is set by default.

    Your original code produces the "un-expected" result for me in Local version 4.0.0-alpha.3, I don't know why it worked differently in alpha.2. Given the escaping issues I would say the "un-expected" result is the correct result, as the base either cannot be determined or is null.

    Interestingly, the problem can be fixed by simply using this:

    return gulp.src(['app\\images/**\\*.*'])  // note the one forward slash

    Apparently that is enough to allow the base to be accurately determined. Of course, as the docs say, only forward slashes should be used in the glob portion.

    So that explains the problem with your code but not why the heck you got different results in gulp@4.0.0-alpha.2 but not alpha.3 or 4.0.2???? But I strongly suspect it is related to gulp alpha src issues. It "worked" in alpha.2 but working was itself a bug, it shouldn't have worked and that bug (which allowed incorrect code to work) was fixed later.