Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a better error handler #121

Open
tomsotte opened this issue Jul 13, 2017 · 5 comments
Open

Implement a better error handler #121

tomsotte opened this issue Jul 13, 2017 · 5 comments

Comments

@tomsotte
Copy link

I wanted to make a gulp watch task, but every time it stopped when an error were found.
Since I've searched but found no real workaround, the only solution I found was to handle the error like gulp-sass does. It does not interrupt the watch and just report it on the console.

Solution source: https://github.com/dlmanning/gulp-sass/blob/master/index.js#L178

An easy implementation for whoever has problem with it is:

const babel = require('gulp-babel');

babel.logError = function logError(error) {
	gutil.log(error.toString(), '\n\b', error.codeFrame);
	this.emit('end');
};

// how to use
babel({...})
.on('error', babel.logError)
@n1ru4l
Copy link

n1ru4l commented Aug 3, 2017

Would be cool to have something similar to https://github.com/adametry/gulp-eslint

  gulp.src(src)
    .pipe(babel())
    .pipe(babel.format())

@thenamankumar
Copy link

@tomsotte I guess giving the user, chance to work around error event is better than just logging and not throwing an error.

User may need to do something when error event is fired. I am also doing it the same way you are while working with watchers.

@tomsotte
Copy link
Author

tomsotte commented Aug 27, 2017

@hereisnaman what I am proposing does not exclude your use case, it's an addition, it just eases the logging of the error, which it seems to me is the most common case for the compilation of sass.

@demurgos
Copy link
Member

I agree that we need a better error handler. It should not automatically log errors but simply give the user the ability to add its own custom handler.

Not stopping in watch-mode could be a specific option.

@tomsotte
Copy link
Author

It is in fact what I'm proposing, a nifty addition that does not change in any way the current implementation.
It just simplifies and reduce code for the developer who just need to log errors while on watch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants