That's correct. I can't really tell if it's a bad practice to do that as a package author. I wonder how npm enterprise are going to address that issue, I suppose it's the same issue.
Regarding Artifactory, you could always implement a user plugin <http://www.jfrog.com/confluence/display/RTF/User+Plugins> which will intercept the metadata sent to the client and replaces any external URLs. For Artifactory to do that it's quite complex since it can be any arbitrary URL. Furthermore, for it to work you will need a remote repository pre-configured in Artifactory to that external URL, if you find a package going to the same one that will be easy but in the general case it looks kind of impossible. Personally I haven't heard too many cases of packages doing that so I guess it's quite rare? Regards, Shay On Fri, Nov 7, 2014 at 4:08 AM, eatdrinksleepcode < [email protected]> wrote: > NPM packages are allowed to specify arbitrary urls to tarballs or Git urls > as > dependencies. Such dependencies are downloaded automatically when the > dependent package is installed. In the case of an Artifactory remote > repository proxying a remote NPM registry, this would prevent Artifactory > from caching that dependency. Even worse, in an environment where the > client > does not have external internet access and is supposed to get all of its > dependencies from Artifactory, the installation would fail. > > I cannot find any information on how (or if) Artifactory deals with this > problem. The only solution I can imagine would be rewriting the > package.json > file, which is invasive enough that I would think I would be able to find a > reference to it if it were happening. Is this just an accepted limitation: > a > package that specifies an external dependency will bypass Artifactory? > > How significant of a problem is this in the real world? Do many packages > specify external dependencies this way? > > I ask because I am trying to write a plugin for Artifactory that enables it > to operate as a proxy for Composer, the dependency management tool for PHP. > Composer has this similar problem of external dependencies, but even worse. > I am hoping that understanding how Artifactory treats NPM will be helpful. > > > > -- > View this message in context: > http://forums.jfrog.org/NPM-remote-repositories-and-external-dependencies-tp7580039.html > Sent from the Artifactory - Users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Artifactory-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/artifactory-users >
------------------------------------------------------------------------------
_______________________________________________ Artifactory-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/artifactory-users
