> > 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? > > >> > > > > >> > > > >> > > >
