Sourcing files from a folder that doesn't exist using a glob pattern gives a cryptic error instead of nothing happening

[datho7561]

What were you expecting to happen?

Nothing (build succeeds with v4)

What actually happened?

Cryptic error

Please give us a sample of your gulpfile

Minimal reproducer: https://github.com/datho7561/gulp-glob-src-bug-reproducer

Terminal output / screenshots

npm run build

> [email protected] build
> gulp my-broken-task

[17:27:38] Using gulpfile ~/Documents/Projects/example-gulp/gulpfile.js
[17:27:38] Starting 'my-broken-task'...
[17:27:38] Finished 'my-broken-task' after 4.52 ms
node:events:492
      throw er; // Unhandled 'error' event
      ^

<ref *2> Error: ENOENT: no such file or directory, scandir '/home/davthomp/Documents/Projects/example-gulp/libs'
Emitted 'error' event on Domain instance at:
    at Transform.emit (node:domain:539:12)
    at ReadableState.afterDestroy (/home/davthomp/Documents/Projects/example-gulp/node_modules/streamx/index.js:493:19)
    at Transform._destroy (/home/davthomp/Documents/Projects/example-gulp/node_modules/streamx/index.js:629:5)
    at ReadableState.updateNonPrimary (/home/davthomp/Documents/Projects/example-gulp/node_modules/streamx/index.js:386:16)
    at ReadableState.update (/home/davthomp/Documents/Projects/example-gulp/node_modules/streamx/index.js:367:71)
    at ReadableState.updateReadNT (/home/davthomp/Documents/Projects/example-gulp/node_modules/streamx/index.js:536:10)
    at process.processTicksAndRejections (node:internal/process/task_queues:77:11) {

Followed by a large JavaScript object output as JSON

Please provide the following information:

• Fedora Linux 39
• 20.10.0
• 10.2.3
• 5.0.0

Additional information

I think it's good that sourcing files from a folder that doesn't exist causes the build to fail, but I think the error message should be more clear and less noisy.

[phated]

Thanks for the report. I think I know where to fix this but it'll take some time.

We'll probably move this issue over to the glob-stream repository, as that's where the bug exists.

[scottlet]

I also hit this trying to upgrade to Gulp 5. Gulp 4 used to silently skip missing directories, is there any plan to support an option to include this behaviour in 5? I’d like to not have to test every directory exists before trying to copy it as I’m not responsible for the sources that may or may not exist

[tinogo]

I've just stumpled upon this error, too. Would be really nice, if you could introduce an option to "restore" the old behaviour. :)

[phated]

@tinogo it's a bug. We'll fix it when we have time.

[pavelhoral]

FYI there is an easy (but ugly) workaround - you just need to make the glob start before any potentially missing stuff:

gulp.src('{lib,__IGNORE_MISSING}/*.jar, { allowEmpty: true, base: 'lib' });

__IGNORE_MISSING in my example is just a random constant that does not match any potential file or directory.

[XCompWiz]

I spent a day tracking this down. Glad there's already a report for it.

I delved a bit, and the specific location I could get to was onAction calls fs.readdir and then onReadDir will return cp(err) with the "ENOENT: no such file or directory, scandir " error.

I think pavelhoral's solution is to a different problem, as I applied it locally and it did not solve our specific case.

For ours, I think it would be important to check if the path exists before trying to walk it. The base of globs is assumed to exist. This was not previously the case in 7.0.0 or earlier.

Not throwing the error in onReaddir, in the same way onStat ignores any errors, would likely work very easily, but I'm uncertain if there could be other errors that would be important to catch, such as when reading through symlinks or drive permission issues.

A more robust solution would be to add a "prewalk" action which stats the path, ignores errors with empty callback, and queues the walk action on the path in any other case.

[Donov4n]

I'm well aware that this kind of comment isn't generally welcome, but hey ...

Any news about this BUG? It's been 8 months and no news ... Between that and the deprecation warnings now triggered by the gulp's related deps (vinyl) (to remain compatible with a version of Node that reached the end of its life almost 10 years ago...) it's getting really complicated to maintain the use of this project in a modern stack... :/

[phated]

@Donov4n you are right that they are not welcome. Let me give a few reasons why:

1. In those last 8 months, I've lost my place to live and had generous friends take my family in which required hauling our belongings from one end of the US to the other. When we thought we found a place to land, our car was promptly stolen and our search began anew. We're still relying on the generosity of friends since insurance fought us for months and didn't pay to get a new vehicle.

2. Check your entitlement. Open source maintainers don't owe you anything. It's explicitly stated in the license. Life and family takes 100% priority.

3. We write everything in pure JS with no build process so you can swap out any dependency using npm overrides. This was an explicit design choice because of item 2 above.