Constructor behavior when path and history are provided

[phated]

I noticed in the PR (#94) that history is reset if a vinyl object is constructed with both a path and history property; e.g. new Vinyl({ path: '/pets/cat', history: ['/pets/dog'] }) has ['/pets/cat'] as the history.

Shouldn't the constructor append the new path to the history if we specify both? In my example, it would result in ['/pets/dog', '/pets/cat'] as the history on the new object.

/cc @contra

[phated]

@contra @darsain @Marak @erikkemperman any thoughts on this?

[darsain]

I'm all for appending to history. Makes sense.

[erikkemperman]

It does sound very reasonable to append... But I notice that current behaviour does seem deliberate:

Path history. Has no effect if options.path is passed.

https://github.com/gulpjs/vinyl/blob/master/README.md#optionshistory

[phated]

@erikkemperman it would be a breaking change to be queued up for the 2.0 release. I can't see a reason for it to have no effect.

[phated]

Side notes: It looks like the original implementation in #24 had that behavior and then an issue for history cloning was noted in #35 (with the fix in d220c85). None of those mentioned or took into account what I am mentioning. But the docs for the feature were written in #48 which were just based on the behavior as implemented, as opposed to a conscious decision.

[erikkemperman]

Agreed, I think it makes a lot of sense. Just wanted to point out that the way it is now looked deliberate.

[phated]

@erikkemperman understandable, that's why I did the digging to see if it was. It doesn't seem to be. Maybe the path needs to be compared to the last history item before being set. If it is the same, don't add to history.

[erikkemperman]

The setter for path already compares to the last element in history, so that would certainly be consistent.
https://github.com/gulpjs/vinyl/blob/master/index.js#L264

[phated]

Cool. I think there's a way to leverage that behavior in these changes then.