-
-
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
Changes from 1 commit
4392605
15af3e5
b447d5e
21d7528
5876564
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
'use strict'; | ||
|
||
var assign = require('object-assign'); | ||
var path = require('path'); | ||
var through2 = require('through2'); | ||
var mkdirp = require('mkdirp'); | ||
var fs = require('graceful-fs'); | ||
|
||
function symlink(outFolder, opt) { | ||
opt = opt || {}; | ||
if (typeof outFolder !== 'string' && typeof outFolder !== 'function') { | ||
throw new Error('Invalid output folder'); | ||
} | ||
|
||
var options = assign({ | ||
cwd: process.cwd() | ||
}, opt); | ||
|
||
var cwd = path.resolve(options.cwd); | ||
|
||
function linkFile (file, enc, cb) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. most of the logic in this function is duplicated between dest and symlink. It would be cool if we could split this out to clean them both up There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed. I'll do so. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @JonAbrams There is another PR open to add support for a mode param to .dest that splitting the logic out will conflict with heavily FYI There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So should we wait until both PRs are merged? If I consolidate the logic into a common file, it will indeed conflict with the other PR. I have no problem with waiting until after the PRs are accepted. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @JonAbrams I'll merge this one and then reimplement the other one on top of these changes, there is some more work to be done on that one anyways There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 Let me know if you need any other changes/additions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @JonAbrams Just the logic consolidation and then I think we are ready to merge and publish 👍 |
||
var basePath; | ||
if (typeof outFolder === 'string') { | ||
basePath = path.resolve(cwd, outFolder); | ||
} | ||
if (typeof outFolder === 'function') { | ||
basePath = path.resolve(cwd, outFolder(file)); | ||
} | ||
var writePath = path.resolve(basePath, file.relative); | ||
var writeFolder = path.dirname(writePath); | ||
var srcPath = file.path; | ||
|
||
// wire up new properties | ||
file.stat = file.stat ? file.stat : new fs.Stats(); | ||
file.stat.mode = (options.mode || file.stat.mode); | ||
file.cwd = cwd; | ||
file.base = basePath; | ||
file.path = writePath; | ||
|
||
// mkdirp the folder the file is going in | ||
mkdirp(writeFolder, function(err){ | ||
if (err) { | ||
return cb(err); | ||
} | ||
fs.symlink(srcPath, writePath, function (err) { | ||
if (err && err.code !== 'EEXIST') { | ||
return cb(err); | ||
} | ||
|
||
cb(null, file); | ||
}); | ||
}); | ||
} | ||
|
||
var stream = through2.obj(linkFile); | ||
// TODO: option for either backpressure or lossy | ||
stream.resume(); | ||
return stream; | ||
} | ||
|
||
module.exports = symlink; |
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