Should it add file.origin property

[popomore]

Some plugin like gulp-rev will change file.path, and save the original path with file.revOrigPath.

I think it's nice that supporting by vinyl.

[yocontra]

This seems non-standard - what are the reasons for adding this?

[popomore]

Yeah, but it can be standard.

If I use some plugin that change the path, and the plugins will save origin path by different name. I don't know where is the real path.

gulp.src('*.less') // a.less
  .pipe(less()) // change a.css, save file.lessOriginPath
  .pipe(rev()) // change a-592823.css. save file.revOriginPath
  .pipe(myPlugin()) // want to get origin file.path

[yocontra]

Can you give an example of a plugin?

[popomore]

Sorry for late response.

For example, write a myPlugin above, I want to generate a map that refer to the original file.

module.exports = function(filename) {
  var map = {};
  throught.obj(function(file, enc, cb) {
    map[file.originPath] = file.path;
    this.push(file);
    cb();
  }, function(cb) {
    fs.writeFileSync(filename, JSON.stringify(map));
    cb();
  });
};

yield

{
  "a.less": "a-592823.css"
}

[popomore]

@contra can you see it?

[dgbeck]

The same underlying issue is described in #17.

The original path is a missing concept in the vinyl stream object. Vinyl is billed as a virtual file format - there needs to a way figure out reliably to which real file the virtual file corresponds. Clearly this information is useful and there is nowhere else to get it from.

The solution proposed here is also cool in that does not break backwards compatibility. Implementation seems straight forward. I'd like to see this problem solved. @contra will you consider a PR?

[yocontra]

It's not that I don't agree, but I don't think this goes far enough. Do you think every time the path is modified we should keep a history of that? We can have a setter on the path field that pushes the previous version to a history array. To get the original one you can do history[0]

[popomore]

that's a good idea—
Sent from Mailbox for iPhone

On Sat, Jun 28, 2014 at 3:23 PM, Eric Schoffstall
[email protected] wrote:

It's not that I don't agree, but I don't think this goes far enough. Do you think every time the path is modified we should keep a history of that? We can have a setter on the path field that pushes the previous version to a history array. To get the original one you can do history[0]

Reply to this email directly or view it on GitHub:
#19 (comment)

[dgbeck]

I see. That would certainly solve the issue and is future-proof.

I dunno though... Since the intermediate names don't really point to anywhere real I don't see why they would be needed. @popomore to be clear for your use case you just need the original names right?

Thinking out load here, looking just at the semantics it seems like there are three separate concepts..

1. The full path of the original file (read only). That is needed for maps and some other use cases where it is important to be able to trace a vinyl object back to its source file.
2. The output file extension (read / write). This is needed so that transforms can manipulate it and then the output file has the correct extension. (It can also be used a bit awkwardly to avoid double transforms, like when the same transform is applied locally and globally.)
3. The output file name (read / write). This is needed when the transform needs to change the name of the file for some reason, one use case being the rev() transform above.

(2) and (3) can be combined into one property, which is effectively the dual purpose the path property currently serves. (It seems like a bit of a misnomer since the directory part of the path is not used, but it gets the job done.) Adding an originalPath property would take care of (1).

I can't think of a case where the intermediate values would be useful further done the pipe. Once they have been changed they don't refer to anything useful or persistent. Would a transform every need to know that a file was of a certain type at some point but no longer? Maybe for the the double transform issue mentioned in (2) above. Seems very frail to rely on file extensions like that though, probably doesn't make sense to cater to that awkward use case.

Unless there is a good use case at hand I'd say best to keep it simple with a single property. Has the advantage of not requiring that existing transforms be updated to push to history. Either approach would solve the issue at hand though.

Thanks for looking at this @contra ! Let me know if you'd like a PR for either approach.

[sindresorhus]

I agree with @dgbeck. I only see a use-case for the originalPath.

[popomore]

Yeah, but history can record every change, maybe it's useful in some complex building system.

[yocontra]

I only see a use-case for the original path, but I think all of the info could be useful in visualizing builds and debugging

[sindresorhus]

but I think all of the info could be useful in visualizing builds and debugging

I don't. We can add it later if there's an actual need, but right now it's just unnecessary bloat.

[yocontra]

future proof or bloat, undecided

[popomore]

Have been merged