-
-
Notifications
You must be signed in to change notification settings - Fork 156
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
Add symlink support (Fixes #42) #49
Conversation
- On write the stream will create a symbolic link (i.e. symlink) on disk at the folder/cwd specified. | ||
- After creating the symbolic link, it will be emitted from the stream so you can keep piping these around. | ||
- The file will be modified after being written to this stream: | ||
- `cwd`, `base`, and `path` will be overwritten to match the folder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you read in some files, symlink, then symlink again. you have the original files, a pointer to the original files, and a pointer to the pointer to the original files. does that sound right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so. Basically a vinyl file object is read in from the stream, a symlink is created pointing to it on disk, then the vinyl object is altered to point to the symlink and it's written back to the stream.
I thought this behaviour would be the most similar to dest's behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JonAbrams Yeah, this is how dest works just curious if this seems right for symlinks which is a lot differnet.
@sindresorhus @phated thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had actually first had it return the original files, untouched, after the symlinks were created, but considering the two possibilities, either return the original file or the new symlink, the latter seemed to behave more like dest
(since dest returns the newly written file) which would be "least surprising" for the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JonAbrams Fair enough, I think we can keep this behavior
1 similar comment
var mkdirp = require('mkdirp'); | ||
var fs = require('graceful-fs'); | ||
|
||
exports.prepDestAndResponse = function (outFolder, file, opt, cb) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a fan of lib/common
- would much rather just have lib/prepareWrite.js
which exports a function.
var through2 = require('through2'); | ||
var mkdirp = require('mkdirp'); | ||
var fs = require('graceful-fs'); | ||
var prewrite = require('../prepareWrite'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
var name and file name should be the same
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you prefer prewrite or prepareWrite? I'd go with prepareWrite if it's all the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JonAbrams prepareWrite is fine
var mkdirp = require('mkdirp'); | ||
var fs = require('graceful-fs'); | ||
|
||
module.exports = function (outFolder, file, opt, cb) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
test for this fn?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other support functions in lib/dest don't have unit tests. I thought since the code coverage didn't change (and no new functionality was added) extra tests wouldn't be needed. The existing feature tests in test/dest.js
and test/symlink.js
seem to cover it just fine too.
If you still think it's required I can whip something up tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JonAbrams I can write some tests for this. Usually any function that had to be split into it's own file I'll do tests for. Smaller support functions within a file don't need specific testing IMO.
Add symlink support (Fixes #42)
Add symlink support (Fixes #42)
It's missing the option for relative symlinking, but this should hopefully do the trick for now. Merry Xmas!