One thing about link, is that it makes a lot of sense when you have the notion of global vs local modules. E.g. it can make global modules depend on local ones, and local ones depend on global ones. By double-linking, you can make local ones depend on other local ones through the global one. Cordova doesn't have the notion of globally-installed plugins, so the concept doesn't really map well.
On Sun, Sep 22, 2013 at 11:04 AM, Michael Brooks <mich...@michaelbrooks.ca>wrote: > > > > Can you iterate the reasons? I've enjoyed link but maybe I'm lucky. > > > npm link has been great for me as well. I'd love to hear about the > pitfalls. > > The only one I've experienced is accidentally publishing a package and > forgetting to publish an updated dependency that I locally linked. However, > Travis-CI immediately catches the error thanks to the test suite. > > > On Sun, Sep 22, 2013 at 4:49 PM, Brian LeRoux <b...@brian.io> wrote: > > > Can you iterate the reasons? I've enjoyed link but maybe I'm lucky. > > On Sep 20, 2013 1:33 PM, "Anis KADRI" <anis.ka...@gmail.com> wrote: > > > > > "link is messy". says one nodejs wise man. I want to stay as far away > > > from it as possible for so many different reasons. > > > > > > plugman doesn't fetch anything from registry if version is in the > > > cache. The version lands in the cache if you publish it yourself. It's > > > not cached when you fetch/install. Therefore if the plugin is not your > > > plugin, you need to make sure that the version is up to date because > > > the tool assumes it is since it's _your_ plugin. Do we still need a > > > local registry in this case ? The cache could be the local registry. > > > > > > > > > > > > On Fri, Sep 20, 2013 at 12:40 PM, Brian LeRoux <b...@brian.io> wrote: > > > > `npm help link` > > > > > > > > > > > > On Thu, Sep 19, 2013 at 9:03 PM, David Kemp <drk...@google.com> > wrote: > > > > > > > >> +1 for project specific registry (not home dir) > > > >> > > > >> > > > >> On Thu, Sep 19, 2013 at 2:59 PM, Braden Shepherdson < > > > bra...@chromium.org > > > >> >wrote: > > > >> > > > >> > One alternative is to symlink it into $HOME/.plugman/cache/ > > > my.plugin.id. > > > >> > Then plugman when fetching it will use that, assuming the version > is > > > new > > > >> > enough. I think the right place for the file is in > > > >> > ~/.plugman/localRegistry.json or similar, since fetching plugins > is > > > >> > definitely plugman's responsibility and not CLI's. > > > >> > > > > >> > Braden > > > >> > > > > >> > > > > >> > On Thu, Sep 19, 2013 at 2:56 PM, Andrew Grieve < > > agri...@chromium.org> > > > >> > wrote: > > > >> > > > > >> > > The logic is: > > > >> > > - If there's a url, use it, otherwise use the registry. > > > >> > > > > > >> > > If I'm developing on a plugin, and that plugin has a > dependency, I > > > >> don't > > > >> > > want it fetching it from the registry. I could change the > > > <dependency> > > > >> to > > > >> > > have a url= to the local path, but then I need to remember to > take > > > that > > > >> > out > > > >> > > before publishing. > > > >> > > > > > >> > > So... I'm thinking it would be useful to allow projects to > provide > > > >> their > > > >> > > own file-backed local registry. E.g. a JSON file of pluginId -> > > > >> url/path. > > > >> > > Where the new algorithm would be: > > > >> > > > > > >> > > if id in localRegistry, use that url, otherwise, use the > registry. > > > >> > > > > > >> > > I think this will be super useful for projects that want to > > > distribute > > > >> > > plugins off-registry as well. > > > >> > > > > > >> > > Question is - where's the best place for this? > > > >> > > > > > >> > > My first thought was in CLI's .cordova/config.json, but that > won't > > > work > > > >> > for > > > >> > > plugman projects. homedir may address some use-cases, but > > > >> > project-specific > > > >> > > local registry is still important I think. So... Maybe for CLI > > > >> projects, > > > >> > we > > > >> > > put it in .cordova/config.json and for plugman you use a > > > >> > > --localregistry=FILE flag? > > > >> > > > > > >> > > > > >> > > > > > >
