PluginError and inconsistent showStack output about gulp-util

[yocontra]

What version of gulp-util are you on? This was fixed in the 3.0 release AFAIK

[shellscape]

That was generated using gulp-util 3.0.1

[yocontra]

cc @mtscout6 who wrote this portion of gulp-util

[mtscout6]

The problem is that the Error.stack property is prefixed with the error message. Less than Ideal I agree, but this is a "feature" of Node! 😒

So originally gulp-util was trying to manage the output of the stack trace in the toString function. The problem with this is that since the stack property in turn calls the toString function to get the message we were getting a stack overflow exception due to the infinite recursion. At the time I was more focused on fixing the stack overflow exception so I didn't take the time to strip out the duplicated message.

[shellscape]

@mtscout6 is the duplicated message something that'll be removed in the future, or is it just an acceptable type of thing? I'm wiring up some parsing, so genuinely curious.

Any ideas on the other inconsistencies I mentioned there?

[mtscout6]

It's not something I plan to remove myself, though if someone wished to remove it then they are more than welcome to. There are challenges in doing so in a generic way though. Since the toString function is called and that would be different depending on how various people write those. You can't just strip off the first line since a toString function may yield a multi-line message. Also, what do you do if there is a custom toString that contains a nested exception with that stack trace as well? Where do you trim the result? To the first stack trace, after it, in the middle... It gets complicated real quick. I'm more in favor of simplicity with a little egg on face in place of trying to tackle that.

[shellscape]

Makes total sense.

And about the missing message when using
return new gutil.PluginError(entityName, message, { showStack: true });
Any thoughts there? (see my first post)

[mtscout6]

Looks like I was trying to limit the duplication of the message when showing the stack: https://github.com/gulpjs/gulp-util/blob/master/lib/PluginError.js#L77-L118

[shellscape]

As outlined in this commit for a PR on gulp-recess, use of this constructor form is ignoring/stripping the fileName property of the error object: https://github.com/gilt/gulp-recess/commit/22bc30b079151e63c638ba16588c10c512b799de

I ask in a most humble tone - Is any work planned to clean this up, or will the project be relying on contribution to make changes here?

[yocontra]

@mtscout6 Can you outline possible fixes so somebody else can PR for this?

[shellscape]

I looked at it yesterday, pretty sure that's going to require a refactor of the PluginError module. If I get the chance, I'll do just that. Naturally preferred that the core contributors would give this a priority state, but I get that there may be other fish to fry.

[mtscout6]

@shellscape I don't think this is a problem with gulp-util since I added the following test and it worked just fine:

  it('should apply fileName from options only', function(){
    var realErr = new Error('something broke');
    var err = new util.PluginError('test', realErr, {fileName: 'original.js'});
    err.toString().indexOf('message:').should.equal(-1);
    err.toString().indexOf('fileName:').should.not.equal(-1);
    err.fileName.should.equal('original.js');
  });

The problem is that you are iterating over your error's properties and then emitting an error for each property of the error: https://github.com/gilt/gulp-recess/commit/22bc30b079151e63c638ba16588c10c512b799de#diff-168726dbe96b3ce427e7fedce31bb0bcL38

So the problem is that the el parameter you send into new gutil.PluginError('gulp-recess', el, { fileName: file.path, showStack: false }); is not an Error.

I'd drop the error property iteration you are doing and pass the original error as it stands right into the PluginError.

[mtscout6]

@shellscape If you are still confused check out the PluginError option parser which shows how the options are built up: https://github.com/gulpjs/gulp-util/blob/master/lib/PluginError.js#L9-L30. In particular this line is what I'm referring to when I said that your el parameter is not an Error object.

[shellscape]

@mtscout6 thanks for following up on the missing fileName. That lead me to do some deep diving into less and recess. What I found is that your assumptions about it are correct. The el variable contains a custom object, not inherited from Error.

function LessError(e, env) {
        var input = getInput(e, env),
            loc = getLocation(e.index, input),
            line = loc.line,
            col  = loc.column,
            lines = input.split('\n');

        this.type = e.type || 'Syntax';
        this.message = e.message;
        this.filename = e.filename || env.filename;
        this.index = e.index;
        this.line = typeof(line) === 'number' ? line + 1 : null;
        this.callLine = e.call && (getLocation(e.call, input).line + 1);
        this.callExtract = lines[getLocation(e.call, input).line];
        this.stack = e.stack;
        this.column = col;
        this.extract = [
            lines[line - 1],
            lines[line],
            lines[line + 1]
        ];
    }

I can see two options for improving the experience here:

1. Additional checking to see if a non-Error object was passed, and warning or throwing.
2. Checking to see if the object passed has the common properties of the Error object, and acting as if it were an error.

Do either seem reasonable? @sindresorhus is no slouch of a dev, and if this wasn't immediately obvious to him upon writing the gulp-recess module, I'm sure it's burned a few others as well.

[shellscape]

Also, on this comment: #65 (comment) I made mention that the message was not showing up in the toString() output. I've created this test, which fails:

  it('should show the message with showStack: true', function(){
    var err = new util.PluginError('test', 'it broke', {showStack: true });
    err.message.should.equal('it broke');
    err.toString().indexOf('message:').should.not.equal(-1);
  });

on the err.toString().indexOf('message:').should.not.equal(-1); assertion.

[mtscout6]

And like I mentioned in the follow on comment the message content is there just without the header. Since the message would have been duplicated with the stack trace. Change your test to assert the content of the message's text not the header of the message. ie:

it('should show the message with showStack: true', function(){
    var err = new util.PluginError('test', 'it broke', {showStack: true });
    err.message.should.equal('it broke');
    err.toString().indexOf('it broke').should.not.equal(-1);
  });

[mtscout6]

@shellscape I think that your proposed options would obscure the code more than necessary. Especially since the first example on the readme highlights that you are welcome to omit an existing error in favor of the options object. Checking to see if that object contained common properties of Error would be counterintuitive since you're proposing a dual purpose for that object based on properties that are perfectly viable for both objects. Outputting a warning wouldn't help either since there is a valid use case for it. The best thing to do is change the Readme to state that the error must be an instance of Error.

[shellscape]

👍 to updating the readme. That's a good addition.

I still think there's a problem with the message, but I've made the best case I can. Since we're in disagreement on that and there's an acceptable solution to the Error parameter, I think it's safe to close this one.

[yocontra]

This API is messed up but we have to maintain backwards compat with it :/. The next version of gulp will deprecate gulp-util and recommend people use https://github.com/wearefractal/bettererror which I'm still working on to replace this and remove the insanity

[demurgos]

Closing due to inactivity. Please reopen at gulpjs/plugin-error if needed.