Should give a warning if htmlDependency() is called in a package namespace with system.file()
If htmlDependency() is called in a package namespace with a system.file() argument, this can lead to a subtle problem that will be visible only after a the binary package is built and distributed on CRAN.
For example, in shinybootstrap2, there is this code:
dataTableDependency <- list( htmlDependency( "datatables", "1.10.2", c(file = system.file("www/datatables", package = "shinybootstrap2")), script = "js/jquery.dataTables.min.js" ), htmlDependency( "datatables-bootstrap", "1.10.2", c(file = system.file("www/datatables", package = "shinybootstrap2")), stylesheet = c("css/dataTables.bootstrap.css", "css/dataTables.extra.css"), script = "js/dataTables.bootstrap.js" ) )
This works fine when the package is built and tested on the same machine. However, if the package is built on one machine and then used on another (as is the case with CRAN binary packages), then this will fail -- the dependency will point to the wrong directory on the host.
It fails because system.file() is called at build-time, and the result is stored in the variable dataTableDependency and saved in the binary package. When someone installs the binary package on their machine, the path isn't updated to their path -- it still refers to a path on the machine that built the binaries.
If, on the other hand, htmlDependency() is called from a function at run-time, everything will work fine.
We've also run into this problem with ggvis, and fixed it by converting the variable to a function: rstudio/ggvis@ac65f35
Note: It just so happens that inside of Shiny proper, you can call htmlDependency() and store the results, because Shiny's dependencies use relative paths, without system.file().
This may sound a bit drastic, but I think it would be a good idea have htmlDependency() check if (A) system.file() is called in any of its arguments, and (B) the parent frame is a package namespace. If both of these are true, give a warning or message. I think it would be helpful because otherwise, developers will run into this problem only after their package seems OK and is on CRAN -- and then they'll have a really hard time debugging it, and after they fix it, they'll have to resubmit to CRAN. (This was very confusing for us the first time we saw it, in ggvis, and it was still confusing when we saw it again in shinybootstrap2.)
One more update: I just checked, and shinydashboard also has this problem. :( And as with the other two cases, it would only have been found after sending the package to CRAN.