It’s the same problem one faces when writing R code. While a small script of 300 lines of code will do the job, a large script of 10,000 lines quickly becomes unmanageable. Therefore when tackling more extensive projects, the R programmer will turn to solutions that enforce a specific file structure and provide utilities to harmonise how those files work together. Some of these solutions may include the drake (Landau 2021a) or targets (Landau 2021b) packages, both of which provide tools to manage complex workflows. Another method often used is to build the project as an R package, thereby enforcing a particular structure and enabling reproducibility, unit tests, and more.
4.0.0 will likely run fine on version
There are admittedly few R packages that make use of such technology, though it must be said that many could greatly benefit from it. Given its size and complexity a package such as Shiny, however, could probably not do without it.
These files are processed by Grunt which, using the
Gruntfile.js configuration file in the
tools directory, creates multiple bundles that it places in the
inst folder of the package.
Imagine building a large htmlwidgets for a client only to discover that for IT security reasons all their company laptops run a particular version of a web browser that does not support critical functionalities the widget relies upon.
When writing code, us humans like to use comprehensible variable names, line breaks, spaces, and other things that help make things clear and readable. Machines, however, do not need any of that; as long as the code is valid, it will run.
The minified files of a library tend to end in
.min.js though minified code can very well be placed in a
20.4 Bundling and Modules
While writing an R package, one is free to organise the functions in different files as their content (functions, data, etc.) is ultimately loaded into the global environment with
library by the user of the package.
library() in the web browser, so all the functions, and variables are available. In this paradigm, individual files have to be loaded separately in the browser (as shown below).
While this may be fine for two or three files, it quickly gets out of hand as one has to remember to import those in the correct order. In the above example, variables declared in
main.js cannot be used in
utils.js, unless we change the order of the import in which case something else will likely break.
This may appear like a lot to manage. Thankfully we can use the aforementioned webpack software to take care of all these procedures for us. There is nonetheless a gentle learning curve to make use of it as it involves multiple new concepts.
Another new piece of software that we need to be introduce is Node’s Package Manager, hereafter referred to as NPM. As indicated by the name, it’s a package manager for Node.js, or translated for the R user it’s Node’s loose equivalent of CRAN. One first significant difference is that while CRAN performs very rigorous checks on any package submitted, NPM does not; one can publish almost anything.
Notice how every dependency used in this book had to be either found through a CDN or manually downloaded, only to be imported in the final document. Again, this is useful for the smaller projects but may become a hindrance when multiple dependencies have to be managed and updated, added and removed, etc.
20.7 With R
To be clear, it’s not always necessary to involve webpack and NPM into a project; these can take some time to set up and be excessive for a smaller project. It’s good to be familiar with them as one might want to make use of those in larger projects.
Webpack and NPM were not designed with R in mind, so there are some potential issues to consider when using it in packages and Shiny applications.