devtools R Package: Install, Core Functions and Alternatives

devtools is an R package, published on CRAN, that bundles functions for the everyday tasks of developing an R package: loading code while you edit it, regenerating documentation, running tests, checking the package and preparing it for release. Its own site describes the aim as providing R functions that simplify and expedite common tasks. For researchers it is most useful when analysis code is promoted from a loose script into a small package with documentation and tests. The CRAN page lists version 2.5.2, published 2026-04-30, which requires R 4.1 or later and is released under the MIT licence plus a LICENSE file.

What devtools is used for in research

devtools supports the workflow taught in the R Packages book. Its everyday functions fall into four groups: load and document (load_all(), document()), test (test(), test_coverage()), build and install (install(), build(), update_packages()) and check and release (check(), check_win_release(), check_win_devel(), check_mac_release(), release(), submit_cran()).

In research practice that maps onto reproducibility work. A lab that keeps its cleaning functions, model code and plotting helpers in a package gets a documented interface, a test suite that can be re-run after every change, and an installable unit that collaborators and reviewers can load with one command. The same package can be pinned alongside its dependencies with a lockfile tool such as the one described in our renv guide, and tested in the spirit of the principles in what is unit testing. If you only need to load packages conveniently inside a script, pacman solves a different, smaller problem.

devtools is now a thin wrapper

The devtools site describes what it calls conscious uncoupling: functionality that once lived inside devtools has been split out into other packages, and devtools installs them for you. The packages named are testthat, roxygen2, pak, pkgbuild, pkgload, rcmdcheck, revdepcheck, sessioninfo and usethis. Practically, this means a function you call as devtools::check() is carried out by a specialised package, so a bug report belongs with the package that owns the behaviour, not with devtools. The data table below sets out which package does the work behind the main functions.

Install devtools from CRAN

The official installation route is CRAN. In an R session run:

install.packages("devtools")

To try the development version instead, the devtools site gives:

pak::pak("r-lib/devtools")

That second command needs the pak package to be installed first. On Windows, building packages from source also needs Rtools, covered in the troubleshooting section below.

A step-by-step package workflow with devtools

The steps below follow the “whole game” chapter of R Packages. Each function is quoted as that chapter and the devtools reference name it; arguments beyond the package path are omitted on purpose because they depend on your project.

1. Create the package skeleton. Run create_package() with a path for the new package. The functions create_package(), use_git(), use_mit_license(), use_testthat(), use_github() and use_readme_rmd() come from usethis, which devtools installs and which the book uses to set up version control, a licence, a test folder, a GitHub repository and a README.
2. Put analysis functions in the R folder. Use use_r() to create or open an R script for a function, and write the function there.
3. Load the code you are working on. Run load_all(). The book explains that it simulates the process of building, installing and attaching the package, so your new functions are available without a full install after every edit.
4. Declare dependencies. Run use_package() for each package your functions call. The book is explicit that this adds the package to Imports in the DESCRIPTION file and that “that is all it does”, so you still call functions with the pkg::fun() form in your own code.
5. Document. Write roxygen comments above each function, then run document(). It converts the comments to help files and regenerates NAMESPACE; the devtools site also lists collation among the files it updates.
6. Add tests. Use use_test() to create a test file, then run test(), which runs the tests with testthat. test_coverage() reports how much of the code the tests exercise.
7. Check the package. Run check(). It documents, builds and checks the package locally, and the book describes it as running R CMD check from inside your R session.
8. Install it. Run install() to install the package into your library so other scripts and projects can load it with library(). Use build() to produce a package file, and build_readme() if your README is an R Markdown file.

Illustrative composite: turning an analysis script into a package

This is an illustrative composite, not a real project. Imagine an analyst with a script that cleans a survey export and fits a regression. They move the cleaning step into a function, add roxygen comments, write one test that feeds a small hand-made data frame through it, and run load_all(), document(), test() and check() in that order. When a colleague later edits the cleaning rules, re-running test() shows immediately whether the output has changed. The value is the repeatable test run, not the packaging itself.

Output and how to read it

devtools functions mostly print to the console rather than returning data. load_all() reports loading the package; document() reports the files it writes, such as help files and NAMESPACE; test() prints each test file with its passes, failures and skips through testthat; and check() prints the R CMD check results, where errors must be fixed and warnings and notes are worth reading before release. If a result looks wrong, the underlying package named in the table below owns the behaviour, and its own documentation is the place to look.

The release functions go beyond the local session. check_win_release() and check_win_devel() run checks on Windows and check_mac_release() on macOS, which is how package authors test platforms they do not own; release() and submit_cran() are the steps toward publication on CRAN.

Troubleshooting

Rtools must match your R version on Windows

Rtools provides the toolchains for building R and R packages from source on Windows, and the CRAN Rtools page pairs each Rtools version with a range of R versions. If a build fails on Windows because compilers are missing, check that the Rtools version matches the R version you run.

Rtools version	R version it supports
Rtools 4.5	R 4.5.0 and later
Rtools 4.4	R 4.4.x
Rtools 4.3	R 4.3.x
Rtools 4.2	R 4.2.x
Rtools 4.0	R 4.0.0 to 4.1.3

R version too old for the current release

The current CRAN release of devtools needs R 4.1 or later and usethis 3.2.1 or later. On an older R, the install will not offer the current version, so update R before blaming the package.

install_github() and the install_* family

Older tutorials install code from GitHub with devtools::install_github("user/repo"). The devtools reference lists the install_* family (install_github, install_gitlab, install_bitbucket, install_url, install_local and install_version) on a deprecated page, and recommends pak::pak("user/repo") for that job. For your own packages and apps, the devtools site advises depending on the particular package directly rather than on devtools.

Free alternatives and companions

devtools itself is free under the MIT licence. Because its functions are thin wrappers, several of the packages it installs can be used on their own. The table lists those the devtools site names.

Package	Use it directly when	Source
pak	You only need to install packages from CRAN or GitHub, for example pak::pak("user/repo").	devtools site
usethis	You want the project-setup functions (create_package(), use_git(), use_testthat() and similar) without the rest.	R Packages book, devtools site
testthat	You want to run and write tests outside a package workflow.	devtools site
roxygen2	You want to generate documentation and NAMESPACE from comments.	devtools site

If you are choosing a language for a project rather than a tool within R, our SPSS vs R comparison covers that separate decision. For citing research software you build, the CodeMeta metadata vocabulary is one way to describe it.

Frequently asked questions

What is the devtools R package?

It is a CRAN package, version 2.5.2 as of the CRAN page checked on 2026-11-14, titled “Tools to Make Developing R Packages Easier”. It collects functions for loading, documenting, testing, checking, building and releasing R packages.

How do I install the devtools R package?

Run install.packages("devtools") to install from CRAN. The development version is installed with pak::pak("r-lib/devtools").

Do I still need devtools to install from GitHub?

No. The devtools site marks the install_* functions as deprecated and prefers pak::pak("user/repo") over devtools::install_github("user/repo").

What does load_all() do?

It simulates building, installing and attaching your package so you can test edited code immediately without reinstalling.

What is the difference between document() and check()?

document() converts roxygen comments into help files and regenerates NAMESPACE. check() documents, builds and checks the package locally by running R CMD check.

Which R version does devtools need?

The CRAN page for version 2.5.2 lists R 4.1 or later.

Sources

• devtools package website, r-lib: https://devtools.r-lib.org/ (checked 2026-11-14)
• CRAN package page, devtools 2.5.2: https://cran.r-project.org/web/packages/devtools/index.html (checked 2026-11-14)
• Wickham and Bryan, R Packages, “The whole game”: https://r-pkgs.org/whole-game.html (checked 2026-11-14)
• Rtools for Windows, CRAN: https://cran.r-project.org/bin/windows/Rtools/ (checked 2026-11-14)