Is gulp.src too strict about input globs? (gulp 4)

In #712, a decision was made to allow an empty array to be passed into gulp.src based on the case made by @wesleytodd. That decision was reverted recently in gulp 4 in is-valid-glob, which is used by vinyl-fs.

Elsewhere, another vinyl-fs dependency, glob-stream, is now also enforcing that individual file references in glob arrays or in singular globs must exist, otherwise a 'File not found with singular glob' error is thrown.

Both of these changes make gulp.src stricter and harder to use. I will sometimes hand arrays to gulp.src that can be empty in some circumstances, or an array of globs, some of which do not match any files (but may in the future).

I started some discussions in a vinyl-fs issue stating the problems I have encountered with the new behavior: https://github.com/gulpjs/vinyl-fs/issues/40#issuecomment-144231884 https://github.com/gulpjs/vinyl-fs/issues/40#issuecomment-144470676 https://github.com/gulpjs/vinyl-fs/issues/40#issuecomment-144572864

It seems there are some anti-patterns in gulpfiles that were the cause of these changes, as @contra mentioned in: https://github.com/gulpjs/vinyl-fs/issues/40#issuecomment-144316357

I would like to make the case for returning to the more forgiving gulp.src. This would require behavior changes to is-valid-glob and glob-stream.

Here’s some examples of the added complexity required now:

// this
function moveVendorCssFiles() {
    return gulp.src(mainBowerFiles({filter: '**/*.css'}), {base: paths.bowerComponents})
    ...
}
// becomes
function moveVendorCssFiles(cb) {
    var bowerCss = mainBowerFiles({filter: '**/*.css'});
    if(bowerCss.length === 0) {
        cb();
        return;
    }
    return gulp.src(bowerCss, {base: paths.bowerComponents})
    ...
}

// this
gulp.src([
    'app/*.module.js',
    'app/**/*.js',
    '.tmp/index.js'
])
...
// becomes
gulp.src(globby.sync([
    'app/*.module.js',
    'app/**/*.js',
    '.tmp/index.js'
]), {base: 'app'})
...

Commence discussion!

[vbud]

To me, this situation is really similar to running a map operation on an empty array - if there is nothing in the source array, there is nothing in the output array. The map operation does not throw an error because the array is empty.

In the same way, if I hand gulp.src nothing, it should do nothing, but it shouldn’t throw an error. Is this a reasonable way of looking at the situation or am I missing something?

@tunnckoCore It seems like we have a philosophical difference 😃. But more importantly I think you are completely mis-representing my position. The gulp-testing repo was for testing current gulp 4.0 behavior, but it is not an example of the kind of thing I want to do. I never want to hand a file to gulp that will never exist - the whole point of my examples is that the file could or will exist, but does not always. The examples I gave at the beginning of this issue are more representative of what I’m trying to do, so please react to those instead.

Also, please don’t get hung up on globby.sync or mainBowerFiles or whatever - they are just examples of some other code resolving files and then handing to gulp. And globby is what I am having to use after these changes were made to pre-resolve files since gulp’s behavior is now stricter.

To @tunnckoCore’s last point about strictness - I’m all for strictness when it is preventing dangerous outcomes. Do you have examples of where this particular strictness in gulp has helped you?

[tunnckoCore]

Okey, just digging around of these issues and read all comments.

I can’t realize what and why you (@vbud and the others against this change) expect something to happen when there’s no such actual file on the file system? And actually, why even you would run gulp “on nothing”. I can’t accept their state. I understand the case, but can’t accept it, it’s pointless for me.

There’s no logic in the https://github.com/vbud/gulp-testing and the examples on the first post of this issue. It’s total overkill to pass nothing (empty thing-ish a.k.a empty array) to gulp and do nothing. And it’s more overkill and more error prone than just writing simple if statement and executes the cb. There’s no logic to run all this hard and slow mechanisms of checks, foreachs, globbing, concat/merge/combine streams, passthroughs and etc stuffs - i mean one word - gulp. It will take 100x more time and more possibilities of errors than just one “if” which only job will be to just check some case (e.g. checking is empty array, then call cb) It’s also overkill to use globby (and even sync calling it… nah) and then to pass the paths to gulp.src

I’m absolutely agreed with https://github.com/gulpjs/vinyl-fs/issues/40#issuecomment-144316357. There are a tons of tutorials and cases which use gulp for everything, instead of just use “normal js code to do it”. They make their lifes harder.

If someone is lazy or don’t know sometimes how to trick some things exactly, it isn’t problem of gulp, or google or whatever. Talking generally. And as you can see there’s always have some workaround for everything. It’s not “harder, stricter, or trickier”, it’s better or at least - correct. It’s a lot better to do it with if statement instead of running something which will do nothing, i mean… absolute no logic. Most of the times it’s better to be trickier instead of be “x, y,z -way”, or “simple/easy”.

That’s why I love strictness and use it everywhere - allows me to do more than crazy things and to have a lot more success and lower issues.

Cheers.