gulpjs / fs-mkdirp-stream Goto Github PK

streamx is a much better stream implementation and we should switch all the projects to use it.

We've had so many issues with graceful-fs, I'm wondering if we should just stop using it.

@contra @coreyfarrell What do you think?

In exploring #2 and gulpjs/async-done#45, I found that Errors generated by syscalls (like ENOENT from a fs.stat) don't seem to have a Stack Trace. You can get them to have one by calling Error.captureStackTrace(err) but we don't do that on any of our errors that come from node's fs module.

@erikkemperman @contra @terinjokes do ya'll think we should capture stack traces before forwarding the errors? It's pretty annoying to track down Error: ENOENT: no such file or directory, stat '/Users/phated/test/testcase-vinyl-bug/outbad'

What were you expecting to happen?

The files/folders get copied from gulp.src to gulp.dest

What actually happened?

Gulp throws an error with no stacktrace.

Please give us a sample of your gulpfile

var gulp = require('gulp');

gulp.task(function copy() {
    return gulp.src('./dist/**/*').pipe(gulp.dest("/run/user/1000/gvfs/mtp:host=OnePlus_IN2025_4f28e22d/Internal shared storage/test/"));
});

Terminal output / screenshots

$ npx gulp copy
[19:52:49] Using gulpfile ~/Documents/VS_Code/testrepo/gulpfile.js
[19:52:49] Starting 'copy'...
[19:52:49] 'copy' errored after 32 ms
[19:52:49] Error: ENOTSUP: operation not supported on socket, chmod '/run/user/1000/gvfs/mtp:host=OnePlus_IN2025_4f28e22d/Internal shared storage/test/build'

Please provide the following information:

• OS & version [e.g. MacOS Catalina 10.15.4]: Ubuntu 21.04
• node version (run node -v): v16.13.1
• npm version (run npm -v): 8.3.0
• gulp version (run gulp -v): CLI version: 2.3.0 Local version: 4.0.2

Additional information

There's no stacktrace, so I don't know where inside of gulp this is coming from, or if it's coming from one of gulp's dependencies. Somewhere, something is trying to chmod the new directories, which is failing because the filesystem doesn't support chmod. Ideally this error would be ignored - if a filesystem doesn't support chmod then there's no reason to try setting permissions.

I've tried overwriting fs.chmod with a no-op like fs.chmod = (p, m, cb) => cb(); but this had no effect.

We should either be using node core streams or streamx in examples.

Like I just did to lead, it helped catch an issue.

I think we can either fix the error case or show a better error. Ref https://github.com/cristianl/testcase-vinyl-bug

cc @erikkemperman

This is a follow-up to #6 (comment) where I pointed out use of a 10.12.0 form of options argument to fs.mkdir. I'm thinking we might want to specify engines.node >=10.12.0 or >=10.13.0 on everything anyways. It is very common in the ecosystem for packages that support node.js 10+ to either require recursive fs.mkdir (10.12.0) or to not support minor releases before LTS (10.13.0).

Supporting 10.0.0 brings little value and will setup a long term conflict with both production and development dependencies. For example eslint 7.0.0 (just released) declares support for node.js ^10.12.0 || >=12.0.0. babel 8 and nyc 16 also will not support node.js 10.0.0 - 10.11.x. These are examples of packages which will explicitly declare non-support for older point releases of 10.x. Many packages will simply declare support for >=10 but only work on >=10.12.0.