R package development Key commands

Run code in the package

Rscript -e "devtools::load_all(); code"

Run all tests

Rscript -e "devtools::test()"

Run all tests for files starting with

Rscript -e "devtools::test(filter = '^{name}')"

Run all tests for R/{name}.R

Rscript -e "devtools::test_active_file('R/{name}.R')"

Run a single test "blah" for R/{name}.R

Rscript -e "devtools::test_active_file('R/{name}.R', desc = 'blah')"

Redocument the package

Rscript -e "devtools::document()"

Check pkgdown documentation

Rscript -e "pkgdown::check_pkgdown()"

Check the package with R CMD check

Rscript -e "devtools::check()"

Format code

air format . Coding Always run air format . after generating code. Use the base pipe operator ( |> ) not the magrittr pipe ( %> ). Use () ... for single-line anonymous functions. For all other cases, use function() {...} . Testing Tests for R/{name}.R go in tests/testthat/test-{name}.R . All new code should have an accompanying test. If there are existing tests, place new tests next to similar existing tests. Strive to keep tests minimal with few comments. Avoid expect_true() and expect_false() in favour of a specific expectation which will give a better failure message. When testing errors and warnings, don't use expect_error() or expect_warning() . Instead, use expect_snapshot(error = TRUE) for errors and expect_snapshot() for warnings because these allow the user to review the full text of the output. Documentation Every user-facing function should be exported and have roxygen2 documentation. Wrap roxygen comments at 80 characters. Internal functions should not have roxygen documentation. Whenever you add a new (non-internal) documentation topic, also add the topic to _pkgdown.yml . Always re-document the package after changing a roxygen2 comment. Use pkgdown::check_pkgdown() to check that all topics are included in the reference index. NEWS.md Every user-facing change should be given a bullet in NEWS.md . Do not add bullets for small documentation changes or internal refactorings. Each bullet should briefly describe the change to the end user and mention the related issue in parentheses. A bullet can consist of multiple sentences but should not contain any new lines (i.e. DO NOT line wrap). If the change is related to a function, put the name of the function early in the bullet. Order bullets alphabetically by function name. Put all bullets that don't mention function names at the beginning.