Allow alternate archive

[jbblanchet]

It would be great to be able to specify alternate archive locations.

Use case:

Let's say that the website A uses library B, both being built by the same team. If I'm working on both, I want to use a symlink when refering to B from A, so rebuilding B updates A. But team members only working on A want to reference B directly from a git server, without having to clone the repository locally.

For example, in the package.json file I could have:

"volo": {
    "baseUrl": "lib",
    "localDependencies": {
        "a": "symlink:folder/a"
    },
    "dependencies": {
      "a": "github:organization/a/1.0.0"
    }
  }

This way, volo would first try to check for the local dependency. If it isn't found, it would get it from github. Makes sense?

[jrburke]

volo skips dependencies if they are already installed, so it seems like if, after initial installation, you manually remove lib/a and then do ln -s folder/a a inside the lib folder, that would be enough?

I think that would do the trick, so closing as a discussion ticket, but feel free to continue discussion here.

[jbblanchet]

Thanks for your response.

You're right that I can manually create the link. But then I'll have to do it for every dev on the team, for every dependency that they want to work on. volo add -f will also remove the link.

Here's the kind of workflow I had in mind:

I'm working on a website, and I find a bug or a missing feature in a library. I clone the library's repository, run volo add -f, do my changes, they are reflected in my website immediately. Once I'm satisfied, I push the changes to git, delete my local repository, run volo add -f, and SHAZAM! I'm back to pulling my code from github.

Having the possibility to create alternate paths to libraries would let us implement this king of workflow.

BTW, the idea isn't mine. It's being built into asp.net vNext, where local projects can override NuGet dependencies. From Scott Hanselman's blog:

Even better, let’s say NuGet package Foo.Bar has a bug but you’ve only got the NuGet package. You can make a folder called Foo.Bar in our local project and put the source via "git clone" in that folder. This is great for open source projects. That local version overrides the NuGet, allowing you to easily patch bugs locally in libraries while you wait for a new release. When a new fixed NuGet-distributed version shows up, update the version and delete the local source.

I'm not a fan of NuGet for multiple reasons, I'm just pointing that out so you know I'm not the only one who sees a need for such a feature. :)