Error in LESS code causes silent failure?

[joshribakoff]

Normally in the past the only issues I've had with this package is that it crashes the gulp watch on error. I have not changed anything recently, but I just noticed it fails silently instead of crashing now, when I give it invalid LESS inputs:

I start with an empty folder

 ll dist
total 0

I have a gulpfile which is roughly this:

gulp.task('less', function () {
    return gulp.src('./test.less')
        .pipe(less({

        }))
        .pipe(gulp.dest('./dist'));
});

contents of test.less:

body {
  rgba(179, 229, 252, 0.50);
}

back to console, I try to compile:

gulp less
[22:06:49] Warning: gulp version mismatch:
[22:06:49] Global gulp is 3.9.0
[22:06:49] Local gulp is 3.8.11
[22:06:50] Using gulpfile ~/www/isite/snmenus2/gulpfile.js
[22:06:50] Starting 'less'...

That's the full output. I do not get any further error messages (am not checking return codes). No other output occurs. I will list my dist dir again after running gulp less:

ll dist
total 0

If I fix the invalid syntax by prefixing it with "background-color:", it works as expected. I get an output of a "test.css" in my dir, and this gets printed to console:

[22:08:01] Finished 'less' after 33 ms

Those are my actual results. My expected results would to see a LESS error message specifying the line number that is incorrect, printed to stderr of my console.

Thanks!

[psolbach]

+1, just noticed it.

[stephenlacy]

Related to #171
Less is consuming all the errors.

[joshribakoff]

@stevelacy less is not consuming the errors, gulp-less is. Also related to #118 - they recommend checking output of lessc, as you can see, lessc correctly reports the errors:

The only indication of a failure in gulp output is the fact that the task "Less" is started, but no corresponding line indicating it ever finishes shows up in the output. At that point, I have to then manually call lessc to see if there is any error causing it to not complete. Is there any way I can get the output from lessc to dump to console when running it through gulp?!

I've tried the various workarounds mentioned in the issue tracker, registering "on error" callbacks - problem is there are various methods recommended, I'm not sure which syntax is the proper way & none appear to work. Any help?

Furthermore, after fixing the syntax error in my less code, gulp does not attempt to start another "less" task, but the other watch tasks do run. I have to kill the gulp process where I'm running the watch, and manually restart it after fixing the syntax error in my code. Obviously not ideal.

[stephenlacy]

@joshribakoff gulp-less is a through stream. Any functions inside it modify the file, throw errors, etc. In this case less is actually modifying the error with it's JS API inside it's own promise scope.

I manually took out the less render function and replaced it with a normal file parse. It worked correctly without consuming the errors.

But anyway, not to argue on the semantics of the issue I will look into it when I have free time.

[mattsawyer77]

I'm seeing this problem in gulp-less 3.3.0 (I just checked to make sure be18b01 is in my copy of index.js).

Has there been a regression, or is there some other way to capture a parsing error?

[yocontra]

@mattsawyer77 Code?

[mattsawyer77]

@contra My less task is essentially the following:

gulp.task('less', function() {
    var dest = uiRoot + '/css';
    gulpUtil.log('compiling LESS...');

    return gulp.src(sourcePaths.less)
    .pipe(less({
        sourceMap: true
    }))
    .pipe(gulp.dest(dest));
});

I can easily repro this by inserting some invalid characters into a .less file, which results in

Potentially unhandled rejection [2] Unrecognised input. Possibly missing opening '{' in file ***filename here*** line
no. 1

but gulp abruptly stops executing at that point, and I get a 0 exit code. I tried instrumenting the stream with .on('error') and returning a promise which rejects if the stream errors, but the error handler was never called.

If I remove the invalid characters, gulp works fine, and I can see that my less task finishes.

[mattsawyer77]

should I file a new issue for this? Or do you think I'm potentially doing something wrong here?

[yocontra]

gulp.task('less', function() {
    return gulp.src(sourcePaths.less)
      .pipe(less({
          sourceMap: true
      }).on('error', console.log))
      .pipe(gulp.dest(uiRoot + '/css'));
});

Does this log the error for you?

Most people use something like gulp-plumber to wire up error management.

[mattsawyer77]

@contra it does, thank you!

[lwr]

+1 with @mattsawyer77

problem still exists in 3.3.2

I am confused if this problem should be fix in future release?

The workaround #171 (comment) works

gulp.task('less', cb => {
     gulp.src(lessSourcePaths)
         .pipe(less(...))
         .on('error', cb)
         .pipe(gulp.dest(cssDestRoot))
         .on('end', cb);
}

But it's still a very strange behavior that less consumes all errors and we even got a success exit code for gulp process

[lwr]

we are now gulp 4.0.0 + gulp-less 4.0.0

problem still exists

does not work: error printed out but task succeed

gulp.task('less'), () => {
    return gulp.src(lessSourcePaths)
        .pipe(less(...))
        .pipe(gulp.dest(cssDestRoot))
}

not works neither: error totally lost

gulp.task('less'), cb => {
    return gulp.src(lessSourcePaths)
        .pipe(less(...))
        .on('error', cb)
        .pipe(gulp.dest(cssDestRoot))
}

not works neither: error totally lost

gulp.task('less'), cb => {
    gulp.src(lessSourcePaths)
        .pipe(less(...))
        .on('error', cb)
        .pipe(gulp.dest(cssDestRoot))
        .on('end', cb);
}

finally this workaround works

gulp.task('less'), cb => {
    let succeed;
    gulp.src(lessSourcePaths)
        .on('end', () => { succeed = true })
        .pipe(less(...))
        .on('end', () => { succeed && cb() })
        .pipe(gulp.dest(cssDestRoot))
}

if you print a debug message in each on err / on end, you should find out that the end event always trigger before that error event, it made no sense totally, because cb could be called only once

if there's no error, both end callbacks would be called and then finally cb got called

if error occurred, only the first end callback would be called, the second one wouldn't, so cb never called, though error event could be emitted