Add symlink option to grunt.file.copy

[jamesplease]

Ref

Actually, I may have misinterpreted that issue in my early-morning sleepiness. The issue is really that it won't copy symlinks. I'll update this PR accordingly.

Presently, grunt.file.copy will take symlinks and generate new files from them. This change makes it so that symlinks are copied as symlinks.

This first commit is a rough draft showing a really basic implementation of the idea.

[jamesplease]

This is an initial take on this issue. It will copy symlinks as symlinks now, but there are a number of questions that need to be answered.

• Should an option toggle this behavior? What's the default setting for the option?
• It throws an error when the file already exists. Should it automatically overwrite the file? I think that it should, as regular files are overwritten.
• May need to be tested on Windows, though it largely follows the pattern in grunt-contrib-symlink, so if that library works then this one should, as well.

It also needs some unit tests to verify all of this behavior, which I can add once these questions have been worked out.

Further considerations are the incompatibility of copying symlinks with the other options of copy, like process.

//cc @shama

[cowboy]

Default setting: the current behavior. We could have a {preserveSymlinks: true} option.

What throws an error when the file already exists, the current code or your new code? I think it should retain the current behavior, regardless.

Obviously process won't be run on symlinks. That can be documented.

Lots of tests!

[vladikoff]

@jmeas 0.5.0?

[rowanthorpe]

Just chiming in to say I'm really looking forward to when this (nearly 2-year-old) PR, or something like it, is merged. I have a project which is heavy on relative symlinks within its own tree, and copying all those symlinks-as-files multiple times (to various output-dirs based on settings) is really inefficient.

Is there some kind of deadlock of issues causing this not to progress? I see there is a reference from this related PR for grunt-contrib-clean (which is 2.5 years old), and can't understand if there is some "blocker" or if these PRs have just been left to go stale...? If someone knows it is just extra coding-time needed somewhere else, and are too busy, please point me to the issue(s) - I could try to take a look myself.

[k-funk]

+1

[shama]

Hey! Sorry for the massive delay on this. I'd be happy to merge and release on an upcoming minor version. We just need to address the comments @cowboy has made first.

[jamesplease]

I prob. won't have time to update this, so if anyone wants to take it over feel free.

[GuillaumeLeclerc]

Any news ?

[shama]

@GuillaumeLeclerc Feel free to click the "Subscribe" button under notifications on the right. That will give you a notification if there is any news on this PR.