ropensci/targets: a Make-like pipeline tool that treats R functions and R objects as the unit of work

Make, with R objects instead of files

The description of what targets does is the best summary of the package. Pipeline tools coordinate the pieces of computationally demanding analysis projects, and the `targets` package is a Make-like pipeline tool for statistics and data science in R. It skips costly runtime for tasks that are already up to date, orchestrates the necessary computation with implicit parallel computing, and abstracts files as R objects.

That last clause is the difference from Make. In a Make pipeline, each target is a file and the dependency graph is over files. In targets, each target is the result of an R function, and the intermediate state is stored as an R object, so a later stage reads a value rather than opening a file and parsing it.

The consequence the README highlights is trust. If all the current output matches the current upstream code and data, then the whole pipeline is up to date, and the results are more trustworthy than otherwise. That is the claim that matters for a data analysis, where the usual failure is a stale intermediate silently carried into a final result.

The philosophy section fills in the vocabulary. A pipeline is a computational workflow that does statistics, analytics or data science, with examples including forecasting customer behavior, simulating a clinical trial and detecting differential expression from genomics data. A pipeline contains tasks to prepare datasets, run models and summarize results for a business deliverable or a research paper, and the methods behind those tasks are user-defined R functions that live in R scripts, ideally in a folder called `"R/"` in the project. Those tasks are called targets, they run the functions and return R objects, and the package orchestrates the targets and stores the output objects.

So the design is: you write ordinary R functions, you declare the graph, and the package works out what to run.

The workflow is four commands

The usage section is short enough to follow, and the four steps are the whole lifecycle of a pipeline.

First, you write R functions for the pipeline and save them to R scripts, ideally in the `"R/"` folder of your project. Nothing about them is special, they are functions you would call by hand.

Second, you call `use_targets()` to write the key files, including the vital `_targets.R` file which configures and defines the pipeline. This is the scaffolding step, and it is the one piece of boilerplate you accept in exchange for the rest.

Third, you follow the comments in `_targets.R` to fill in the details of your specific pipeline. The file is written with comments explaining what goes where, so this is editing a documented template rather than writing configuration from scratch.

Fourth, you check, run and read:

tar_visnetwork()
tar_make()
tar_read()

The order of those three is the workflow. `tar_visnetwork()` renders the dependency graph, so before you run anything you can see the shape of the pipeline and whether the edges are what you intended. `tar_make()` runs it, skipping the targets that are already up to date. `tar_read()` gives you the output object back as an R value.

That sequence is what makes the package approachable, because the graph is inspectable before it is executed, and a pipeline you can see is a pipeline you can debug.

Installing the release, the development version, and the distributed computing partner

There are three installation routes, and the table is worth reading because the development installs are not the usual source build.

| Type | Source | Command | |----|----|----| | Release | CRAN | `install.packages("targets")` | | Development | GitHub | `pak::pkg_install("ropensci/targets")` | | Development | rOpenSci | `install.packages("targets", repos = "https://dev.ropensci.org")` |

The rOpenSci dev repository is an unusual and useful thing to have, because it gives you a binary or source build of the development version that is not tied to GitHub's source tarballs, and for a package with compiled code that is often the difference between a smooth install and a failed one.

There is also a companion package to install first if you plan to use distributed computing, because targets with crew for distributed computing is recommended to use crew version 0.4.0 or higher:

install.packages("crew")

The mention of a specific minimum version is a hint about the interface, since the version floor usually corresponds to a change in the API the integration depends on. And the separation matters conceptually too. `targets` is the pipeline, and `crew` is the scheduler that decides where the work runs, so the same pipeline can execute locally with implicit parallelism and then move to a cluster without the analysis code changing.

Documentation in three layers, and a help guide for asking questions

The documentation structure is one of the more thoughtful arrangements in the R ecosystem, and it is worth describing because it tells you where to look for what.

The user manual is the in-depth discussion of how to use targets, and the README names the chapters that matter most, the walkthrough, the help guide and the debugging guide. The reference website is the formal documentation of all the user-side functions, the statement of need, and multiple design documents of the internal architecture.

Then there is the developer documentation, which is a separate book of software design documents for the deep internal architecture of the package, aimed at contributors rather than users. The fact that the internal design is documented in public is unusual and is a real sign of how seriously the maintainer treats the code base.

The help guide has a specific purpose that the README states plainly. You are asked to read it to learn how best to ask for help using targets. That is a small thing with a large effect on a package's issue tracker, and it reflects the wider culture of the rOpenSci project.

There is learning material as well. A Carpentries workshop by Joel Nitta exists for teaching the package, and there is a half-day interactive tutorial with a Keras example by Will Landau. The four-minute video demonstrates the same example pipeline used in the walkthrough and functions chapters, with the code available in a separate repository and a cloud project that runs in the browser with no download or installation required.

Talks that show the package under real workloads

The selected talks list is a good index of what people actually use this for, and the three recent ones are the most telling.

The useR! 2025 keynote is on powerful simulation pipelines with targets. The rOpenSci community call on targets in action is with Joel Nitta and Eric Scott. And the R/Pharma 2023 talk covers targets and crew for clinical trial simulation pipelines, which is the hardest version of the problem, since a clinical trial simulation is a large graph of parameterised Monte Carlo runs, and each one is expensive enough that re-running unchanged ones is the difference between a usable and an unusable pipeline.

Earlier entries show the same idea in other domains, with targets and stantargets for Bayesian model validation pipelines from R/Medicine 2021, and a talk on reproducible computation at scale in R from the New York Open Statistical Programming Meetup in December 2020.

The stantargets mention is worth noting for a second reason. It is a separate package built on the same idea, which tells you that the approach generalises beyond one implementation, and the rOpenSci community call format, with two people presenting and a recording on the organization's site, is part of a broader review culture that the badges also point to, with a software review under way at rOpenSci and a journal paper in the Journal of Open Source Software.

Where targets is the wrong tool

The first wrong case is a script that runs in seconds. The package writes a directory of files, defines a graph, and runs a scheduler, and none of that pays for itself when the whole analysis is one function call on a data frame. The overhead is real and the package cannot remove it.

The second is a pipeline whose stages are not R functions. The design stores intermediate results as R objects, so a stage that shells out to a tool and produces a file has to be wrapped, and a stage that produces something R cannot serialise cleanly has to be adapted. A pipeline that is mostly shell and Python with R at the edges fits the tool badly.

The third is a team whose intermediates are files by necessity. A downstream consumer that needs a CSV on disk, a report generator that reads from a path, or a colleague who wants to open an intermediate in a spreadsheet, all push you towards storing files, and `targets` is opinionated about that.

The fourth is a project that is not reproducible enough to benefit. The up to date check compares the current output against the current upstream code and data, and if the pipeline has hidden state, a hard coded path or a manual step, the check is wrong, and a wrong check is worse than no check because it silently skips work that needed doing.

On the state of the project, the release history shows steady maintenance with 1.11.3 in May 2025, 1.11.4 in September 2025 and 1.12.0 in February 2026, and the last push to the repository on 2026-05-13. The package is on CRAN, the repostatus badge says active, and the release names are informative, since 1.11.3 was about initialization speed and pre-processing progress messages and 1.12.0 added a tar_igraph function. The repository itself is a conventional R package with R sources, man pages, tests, vignettes, a pkgdown configuration, a `codemeta.json` and a lintr configuration, and it carries a `LICENSE`, a `LICENSE.md` and a `LICENSE.note`, so the terms are worth reading before an organisation depends on it.

Editorial conclusion

Adopt targets if your R analysis is a multi step pipeline where you re-run expensive stages more often than you should, since the up to date check is what turns a script into a pipeline and the R object storage removes the file format decisions from the middle of your work. Do not adopt it for a single script or a notebook that runs in seconds, because the machinery and the file layout it writes are pure overhead there, and do not assume the R object model will fit a pipeline whose stages are not R functions. Verify first that your dependencies are R functions you can wrap, that the storage of intermediates as R objects suits your downstream tools, which may expect files, and that the licence terms in the repository's LICENSE and LICENSE.note files cover your organisation, since the package is published with a licence that is not one of the standard permissive ones.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. ropensci/targets on GitHub