rOpenSci - open tools for open science

A Better R Programming Experience Thanks to Tree-sitter

rOpenSci — Thu, 02 Apr 2026 00:00:00 +0000

A little bit less than two years ago, building on work by Jim Hester and Kevin Ushey, Davis Vaughan completed a very impactful JavaScript file for the R community: an R grammar for the Tree-sitter parsing generator. He even got a round of applause for it during a talk at the useR! 2024 conference! So, did he get cheered for… grammatical rules in a JavaScript file? 😅

No, the audience was excited about the improved developer experience for R that this file unlocked. R tooling around Tree-sitter is how you get

reformatting through Air and linting through Jarl;
auto-completion or help on hover in the Positron IDE;
better search for R on GitHub;
and more!

In this post, we’ll explain what Tree-sitter is, and how tools built on Tree-sitter can benefit your R development workflow.

Code parsing: what is Tree-sitter?

Tree-sitter is a code parsing generator written in C, with bindings existing in several languages including Rust (and R!).

Let’s rewind a little bit. What does it mean to parse code?

Basically, given a string of code like

a <- mean(x, na.rm = TRUE)

How do you know that mean is a function name, na.rm an argument name, TRUE a logical? You have to parse that code into what’s called a parse tree. You do that in your head when reading R code. 😸

R itself can obviously parse R code, thanks to its grammar. See for instance the commit that introduced R’s native pipe, which necessitated extending R’s syntax thus modifying its grammar.

You can use parse() and getParseData() to parse R code.

parse(
 text = "a <- mean(x, na.rm = TRUE)",
 keep.source = TRUE
) |>
 getParseData()
#> line1 col1 line2 col2 id parent token terminal text
#> 23 1 1 1 26 23 0 expr FALSE 
#> 1 1 1 1 1 1 3 SYMBOL TRUE a
#> 3 1 1 1 1 3 23 expr FALSE 
#> 2 1 3 1 4 2 23 LEFT_ASSIGN TRUE <-
#> 21 1 6 1 26 21 23 expr FALSE 
#> 4 1 6 1 9 4 6 SYMBOL_FUNCTION_CALL TRUE mean
#> 6 1 6 1 9 6 21 expr FALSE 
#> 5 1 10 1 10 5 21 '(' TRUE (
#> 7 1 11 1 11 7 9 SYMBOL TRUE x
#> 9 1 11 1 11 9 21 expr FALSE 
#> 8 1 12 1 12 8 21 ',' TRUE ,
#> 13 1 14 1 18 13 21 SYMBOL_SUB TRUE na.rm
#> 14 1 20 1 20 14 21 EQ_SUB TRUE =
#> 15 1 22 1 25 15 16 NUM_CONST TRUE TRUE
#> 16 1 22 1 25 16 21 expr FALSE 
#> 17 1 26 1 26 17 21 ')' TRUE )

Or you could transform that same data into XML using Gábor Csárdi’s {xmlparsedata}:

parse(
 text = "a <- mean(x, na.rm = TRUE)",
 keep.source = TRUE
) |>
 xmlparsedata::xml_parse_data(pretty = TRUE) |>
 xml2::read_xml() |>
 as.character() |>
 cat()
#> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
#> <exprlist>
#> <expr line1="1" col1="1" line2="1" col2="26" start="28" end="53">
#> <expr line1="1" col1="1" line2="1" col2="1" start="28" end="28">
#> <SYMBOL line1="1" col1="1" line2="1" col2="1" start="28" end="28">a</SYMBOL>
#> </expr>
#> <LEFT_ASSIGN line1="1" col1="3" line2="1" col2="4" start="30" end="31">&lt;-</LEFT_ASSIGN>
#> <expr line1="1" col1="6" line2="1" col2="26" start="33" end="53">
#> <expr line1="1" col1="6" line2="1" col2="9" start="33" end="36">
#> <SYMBOL_FUNCTION_CALL line1="1" col1="6" line2="1" col2="9" start="33" end="36">mean</SYMBOL_FUNCTION_CALL>
#> </expr>
#> <OP-LEFT-PAREN line1="1" col1="10" line2="1" col2="10" start="37" end="37">(</OP-LEFT-PAREN>
#> <expr line1="1" col1="11" line2="1" col2="11" start="38" end="38">
#> <SYMBOL line1="1" col1="11" line2="1" col2="11" start="38" end="38">x</SYMBOL>
#> </expr>
#> <OP-COMMA line1="1" col1="12" line2="1" col2="12" start="39" end="39">,</OP-COMMA>
#> <SYMBOL_SUB line1="1" col1="14" line2="1" col2="18" start="41" end="45">na.rm</SYMBOL_SUB>
#> <EQ_SUB line1="1" col1="20" line2="1" col2="20" start="47" end="47">=</EQ_SUB>
#> <expr line1="1" col1="22" line2="1" col2="25" start="49" end="52">
#> <NUM_CONST line1="1" col1="22" line2="1" col2="25" start="49" end="52">TRUE</NUM_CONST>
#> </expr>
#> <OP-RIGHT-PAREN line1="1" col1="26" line2="1" col2="26" start="53" end="53">)</OP-RIGHT-PAREN>
#> </expr>
#> </expr>
#> </exprlist>

In both cases, you recognize words such as LEFT_ASSIGN or SYMBOL_FUNCTION_CALL. Parsing is an essential step before the code is actually executed, but parsed code can also be used for other purposes, such as analyzing code without brittle regular expressions (does it call a particular function?), navigating code (going from a function call to the definition of that function), or modifying code (replacing all occurrences of a function with another one).

Now, Tree-sitter performs this same code parsing but faster especially thanks to its support of incremental parsing – which is key to updating the syntax tree as you are typing in your editor for instance! Tree-sitter is agnostic in that it can parse any code as long as there is a grammar for it (think, Rosetta Stone plugins). It’s been used for many languages which means many tools have been built around it.

To have Tree-sitter “learn” a new language you need to give it a file containing the definition of the syntax of that language, what’s called a grammar. This is where the aforementioned JavaScript file by Davis Vaughan and collaborators comes into play! The treesitter-r repo, which provides a translation of the R grammar in the format expected by Tree-sitter, is the base of all tools presented in this post which use R code as their input.

Here’s how to use the {treesitter} R package for the same code as earlier. The {treesitter} R package allows us to use Tree-sitter from R. To parse R code with it, we need the language() function from {treesitter.r}¹.

library(treesitter)
#> 
#> Attaching package: 'treesitter'
#> The following object is masked from 'package:base':
#> 
#> range
language <- treesitter.r::language()
parser <- parser(language)
text <- "a <- mean(x, na.rm = TRUE)"
parser_parse(parser, text)
#> <tree_sitter_tree>
#> 
#> ── Text ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
#> a <- mean(x, na.rm = TRUE)
#> 
#> ── S-Expression ────────────────────────────────────────────────────────────────────────────────────────────────────────────────
#> (program [(0, 0), (0, 26)]
#> (binary_operator [(0, 0), (0, 26)]
#> lhs: (identifier [(0, 0), (0, 1)])
#> operator: "<-" [(0, 2), (0, 4)]
#> rhs: (call [(0, 5), (0, 26)]
#> function: (identifier [(0, 5), (0, 9)])
#> arguments: (arguments [(0, 9), (0, 26)]
#> open: "(" [(0, 9), (0, 10)]
#> argument: (argument [(0, 10), (0, 11)]
#> value: (identifier [(0, 10), (0, 11)])
#> )
#> (comma [(0, 11), (0, 12)])
#> argument: (argument [(0, 13), (0, 25)]
#> name: (identifier [(0, 13), (0, 18)])
#> "=" [(0, 19), (0, 20)]
#> value: (true [(0, 21), (0, 25)])
#> )
#> close: ")" [(0, 25), (0, 26)]
#> )
#> )
#> )
#> )

Tree-sitter is the workhorse of many tools, that are mentioned in the diagram below. All of them are dependent on tree-sitter and the R grammar provided to it. Some of them are command-line interfaces (CLIs), while others are R packages.

Browsing code interactively: Positron IDE, GitHub

The real reason why the audience applauded Davis Vaughan is that he explained how the R grammar for Tree-sitter had been deployed to GitHub so that we get almost as good experience browsing R code on GitHub as browsing, say, JS code. If we search for a function name in a repository for instance, its definition will be indicated in the search results. See Davis’ slides (also available in PDF), or refer to the video below showing how typing vetiver_model in the search bar from the R vetiver repo makes the function definition the first result, on which one can click to land into the definition.

Also very useful is the use of Tree-sitter by Ark, the R kernel used in the Positron IDE. Ark is how you get autocompletion and help on hover in Positron. The video below shows how you can extend the selection to further steps of a pipeline in Positron.

This use case of Tree-sitter is also featured in Davis’ slides. See also Lionel Henry’s and Davis Vaughan’s talk about Ark at posit conf 2024, especially the part about code assistance.

Other development environments such as Emacs also have support for Tree-sitter.

Searching/browsing code

You can parse and search R code using the {treesitter} R package and treesitter query syntax. The {treesitter} R package is a dependency of the {gander} package by Simon Couch, that is meant to be used for a better experience with LLMs when writing R code. Another use case of the {treesitter} R package is the {igraph.r2cdocs} extension to {roxygen2} for the {igraph} package, that parses all of igraph R code to then be able to identify, for each exported function, whether it (in)directly calls a function whose name ends with _impl, indicating a wrapper to a C igraph function whose docs can be then be linked from the manual of the R function.

The {pkgdepends} package calls Tree-sitter (C) to detect dependencies in files. Below we run it on the source of the saperlipopette R package.

pkgdepends::scan_deps(
 "../../../../../CHAMPIONS/saperlipopette",
 "../../../../../CHAMPIONS"
)
#> 
#> Dependencies:
#> + brio  @ R/blame.R, R/check-editor.R, R/clean-dir.R, R/committed-to-main.R, R/committed-to-wrong-branch.R, R/conflict…
#> + cli  @ inst/exo_bisect-Rprofile.en.R, inst/exo_bisect-Rprofile.es.R, inst/exo_bisect-Rprofile.fr.R, inst/exo_blame-…
#> + devtools  @ saperlipopette.Rproj
#> + fs  @ R/blame.R, R/check-editor.R, R/clean-dir.R, R/committed-to-main.R, R/committed-to-wrong-branch.R, R/conflict…
#> + gert  @ inst/exo_check_editor-Rprofile.en.R, inst/exo_check_editor-Rprofile.es.R, inst/exo_check_editor-Rprofile.fr.…
#> + knitr  @ README.Rmd
#> + parsedate  @ R/utils-git.R
#> + purrr  @ R/create-all.R, R/debug.R, R/log-deleted-file.R, R/log-deleted-line.R, R/revparse.R, R/roxygen2.R, R/worktre…
#> + rlang  @ R/create-all.R, R/roxygen2.R, R/utils-fs.R, R/utils-usethis.R, R/zzz.R
#> + rmarkdown  @ README.Rmd, vignettes/saperlipopette.qmd
#> + roxygen2  @ R/roxygen2.R, saperlipopette.Rproj
#> + saperlipopette @ README.Rmd, vignettes/saperlipopette.qmd
#> + tibble  @ R/roxygen2.R
#> + usethis  @ R/blame.R, R/check-editor.R, R/clean-dir.R, R/committed-to-main.R, R/committed-to-wrong-branch.R, R/conflict…
#> + vctrs  @ R/roxygen2.R
#> + withr  @ R/blame.R, R/check-editor.R, R/clean-dir.R, R/committed-to-main.R, R/committed-to-wrong-branch.R, R/conflict…
#> 
#> Test dependencies:
#> + fs  @ tests/testthat/test-blame.R, tests/testthat/test-check-editor.R, tests/testthat/test-clean-dir.R, tests/test…
#> + gert  @ tests/testthat/test-blame.R, tests/testthat/test-clean-dir.R, tests/testthat/test-committed-to-main.R, tests…
#> + rlang  @ tests/testthat/test-blame.R, tests/testthat/test-check-editor.R, tests/testthat/test-clean-dir.R, tests/test…
#> + saperlipopette @ tests/testthat.R
#> + testthat  @ tests/testthat.R
#> + withr  @ tests/testthat/test-blame.R, tests/testthat/test-check-editor.R, tests/testthat/test-clean-dir.R, tests/test…

ast-grep is a useful tool built on Tree-sitter for searching and re-writing code, with a clearer query syntax than Tree-sitter’s. Its name is reminiscent of grep, but with ast-grep we do not need to write brittle regular expressions 😸. {astgrepr} by Etienne Bacher is an R wrapper to the Rust bindings of ast-grep, and is used in Etienne’s {flir} package for refactoring code.

The ast-grep command-line interface (CLI) itself is featured in a useful blog post by Emil Hvitfeldt where he explains how to document the usage of ast-grep for Claude.

Formatting and linting: Air, Jarl

Speaking of CLIs…

Air, by Davis Vaughan and Lionel Henry, is a CLI built on Tree-sitter, in Rust. It reformats code blazingly fast.

Jarl, by Etienne Bacher, is a CLI built on Air, therefore also on Tree-sitter, in Rust. It lints and fixes code, also blazingly fast. It can even detect unreachable code, unused functions and duplicated function definitions.

In both of these examples, the creation of CLIs wrapping Rust bindings was more efficient than the creation of R packages wrapping the {treesitter} R package, for several reasons:

Rust CLIs can edit code very fast²;
CLIs are integrated in extensions for popular IDEs (for instance Positron);
a CLI is easier to install on CI than an R package that needs, well, an R installation.

More tools

A brief mention of some other interesting tools we’ve explored a bit less.

Configuring: {ts} for parsing JSON and TOML (not R!)

The {ts} package by Gábor Csárdi is the backbone of two R packages used for editing and manipulating:

TOML {tstoml};
JSON {tsjson}.

Compared to existing parsers in R for those formats, these two packages preserve comments.

Testing code: {muttest}

Mutation testing is a kind of testing where you, say, randomly swap + with - in your code (you mutate it) and you run your tests to see whether they catch the mutant. The {muttest} package by Jakub Sobolewski is an R package for mutation testing, that depends on the {treesitter} R package.

Diffing code: difftastic

The difftastic CLI by Wilfred Hughes is “a structural diff tool that understands syntax”. ✨ This means that difftastic doesn’t only compare line or “words” but actual syntax by looking at lines around the lines that changed (by default, 3). Even better, it understands R out of the box. See this blog post with examples of R code diffing.

Conclusion: more to come?

In this post, we’ve presented an overview of Tree-sitter based tooling for R or in R.

Note that this ecosystem of tools is very actively developed, so some tools might come and go. However, the idea that plugging the R grammar into a general parsing generator brings cool features to us R developers, will remain true. Maybe you will contribute to this ecosystem, either through an existing tool or by creating a new one?

We could also parse C code with it using {treesitter.c}. ↩︎
Rust is a lower level language than R so has less overhead; furthermore this kind of Rust code can be easily parallelized. ↩︎

rOpenSci News Digest, March 2026

rOpenSci — Mon, 30 Mar 2026 00:00:00 +0000

Dear rOpenSci friends, it’s time for our monthly news roundup! You can read this post on our blog. Now let’s dive into the activity at and around rOpenSci!

rOpenSci HQ

rOpenSci Dev Guide 1.0.0: Trilingual and Improved

rOpenSci Software Peer Review’s guidance is gathered in an online book that keeps improving! It is now available in English, Spanish and Portuguese. Read more in the release announcement

Champions Program Update

We are still going through the Champions selection process, and we’re excited to share that the new group of mentors has already been selected and is now actively reviewing Champions applications.

This cohort brings together a wonderful mix of returning Champions stepping into mentorship roles, mentors continuing their contributions, and new members joining the program. The 2026 mentors are Andrea Gómez Vargas, Pablo Paccioretti, Alber Hamersson Sánchez Ipia, Erick Isaac Navarro Delgado, Francisco Cardozo, Luis Verde Arregoitia, Monika Ávila Márquez, Guadalupe Pascal, Pao Corrales, and Elio Campitelli. Together, they represent a diverse and vibrant community across Colombia, Mexico, Argentina, Brazil, and Bolivia, with some currently based in Switzerland, Canada, the United States, and Australia. We’re very happy to see this growing, interconnected network supporting the next cohort of Champions.

R-Universe update

You can now download artifacts and log files from R-Universe without being logged in with a GitHub account, for example https://ropensci.r-universe.dev/opencv#checktable.

Software review and usage of AI tools

Authors submitting new software for peer review are now required to explain potential usage of generative AI tools in their package development. All submission templates now include a mandatory check-box:

- [ ] Generative AI tools were used to produce some of the material in this submission.
If so, please describe usage, and include links to any relevant aspects of your repository.

This is the start of our updates to accommodate generative AI tools in package development, as described in our recent blog post. The next phase will involve updates to our Dev Guide, explaining requirements and recommendations for authors, reviewers, and editors. All updates are intended to permit generative AI tools to be used in any useful way, while minimising the burden on those who volunteer their own time to keep our software peer review service running.

Software review bot updates

The ropensci-review-bot now delivers an initial report to all new software pre-submissions and submissions, identifying the five most similar packages from both all rOpenSci packages, and all CRAN packages. The matches are generated by our ropensci-review-tools/pkgmatch package (itself reviewed in this review issue). Matching is based on an “term frequency-inverse document frequency” algorithm, using inverse document frequencies from all rOpenSci and CRAN packages. Similar package reports can also be manually triggered (by editors only) with @ropensci-review-bot similar packages, like in this example for the pkgmatch package itself.

Coworking

Read all about coworking!

Tuesday April 7th 2026, 9:00 Americas Pacific (16:00 UTC) “Getting to know the CSID Network” with Steffi LaZerte and cohosts Irene Ramos and Adamu Saleh Saidu.
- Learn more about the CSID Network
- Meet cohosts, Irene Ramos and Adamu Saleh Saidu, and learn more about the CSID Network and how you might get involved.
Tuesday May 5th 2026, 9:00 Australia Western (01:00 UTC) “Code Review with rOpenSci” with Steffi LaZerte and cohost Liz Hare.
- Explore resources for Code Review
- Sign up to volunteer to do software peer-review at rOpenSci
- Meet cohost, Liz Hare, and discuss resources for Code Review with rOpenSci.

And remember, you can always cowork independently on work related to R, work on packages that tend to be neglected, or work on what ever you need to get done!

Software 📦

New packages

The following package recently became a part of our software suite:

suwo, developed by Marcelo Araya-Salas together with Jorge Elizondo-Calvo and Alejandro Rico-Guevara: Streamline searching/downloading of nature media files (e.g. audios, photos) from online repositories. The package offers functions for obtaining media metadata from online repositories, downloading associated media files and updating data sets with new records. It has been reviewed by Eric R. Scott and Hugo Gruson.

Discover more packages, read more about Software Peer Review.

New versions

The following eleven packages have had an update since the last newsletter: cffr (v1.3.0), pkgmatch (v0.5.2), tarchetypes (0.14.1), rgbif (v3.8.5), saperlipopette (v0.1.1), gutenbergr (v0.5.0), trud (v0.2.1), naijR (v0.7.0), sasquatch (v0.1.3), lingtypology (v1.1.25), and rerddap (v1.2.3).

Post on dfms release: Releasing dfms 1.0: Fast and Feature-Rich Estimation of Dynamic Factor Models in R.

Software Peer Review

There are fifteen recently closed and active submissions and 5 submissions on hold. Issues are at different stages:

One at ‘6/approved’:
- suwo, Access Nature Media Repositories Through R. Submitted by Marcelo Araya-Salas.
One at ‘5/awaiting-reviewer(s)-response’:
- pkgmatch, Find R Packages Matching Either Descriptions or Other R Packages. Submitted by mark padgham.
Two at ‘4/review(s)-in-awaiting-changes’:
- logolink, An Interface for Running NetLogo Simulations. Submitted by Daniel Vartanian.
- galamm, Generalized Additive Latent and Mixed Models. Submitted by Øystein Sørensen. (Stats).
Six at ‘3/reviewer(s)-assigned’:
- pvEBayes, Empirical Bayes Methods for Pharmacovigilance. Submitted by Yihao Tan. (Stats).
- saperlipopette, Create Example Git Messes. Submitted by Maëlle Salmon.
- ernest, A Toolkit for Nested Sampling. Submitted by Kyle Dewsnap. (Stats).
- rcrisp, Automate the Delineation of Urban River Spaces. Submitted by Claudiu Forgaci. (Stats).
- reviser, Tools for Studying Revision Properties in Real-Time Time Series Vintages. Submitted by Marc Burri.
- priorsense, Prior Diagnostics and Sensitivity Analysis. Submitted by Noa Kallioinen. (Stats).
Two at ‘2/seeking-reviewer(s)’:
- nycOpenData, Convenient Access to NYC Open Data API Endpoints. Submitted by Christian Martinez.
- RAMEN, RAMEN: Regional Association of Methylome variability with the Exposome and geNome. Submitted by Erick Navarro-Delgado.
Three at ‘1/editor-checks’:
- RAQSAPI, A Simple Interface to the US EPA Air Quality System Data Mart API. Submitted by mccroweyclinton-EPA.
- fcmconfr, Fuzzy Cognitive Map Analysis in R. Submitted by benroston. (Stats).
- coevolve, Fit Bayesian Generalized Dynamic Phylogenetic Models using Stan. Submitted by Scott Claessens. (Stats).

Find out more about Software Peer Review and how to get involved.

On the blog

Software Review

Software Review in the Era of AI: What We Are Testing at rOpenSci by Mark Padgham, Noam Ross, Maëlle Salmon, Yanina Bellini Saibene, Mauro Lepore, Emily Riederer, Jouni Helske, and Francisco Rodriguez-Sanchez. rOpenSci is testing preliminary policies on the use of generative AI tools, with proposed updates to documentation and procedures for authors submitting software for review, for editors, and for reviewers.
rOpenSci Dev Guide 1.0.0: Trilingual and Improved by Maëlle Salmon, Mark Padgham, and Noam Ross. Updates in version 1.0.0 of the online book ‘rOpenSci Packages: Development, Maintenance, and Peer Review’. Other languages: rOpenSci Dev Guide 1.0.0: Trilingüe y mejorada (es), Guia de desenvolvimento da rOpenSci 1.0.0: trilíngue e aprimorado (pt).

Breaking Release of the patentsview R Package by Russ Allen and Chris Baker. Breaking Release of the patentsview R Package.

Calls for contributions

Calls for maintainers

If you’re interested in maintaining any of the R packages below, you might enjoy reading our blog post What Does It Mean to Maintain a Package?.

NLMR, R package to simulate neutral landscape models. Issue for volunteering.
landscapetools, R package for some of the less-glamorous tasks involved in landscape analysis. Issue for volunteering.
hddtools, Tools to discover hydrological data, accessing catalogues and databases from various data providers. Issue for volunteering.
qualtRics, download Qualtrics survey data. Issue for volunteering.

Calls for contributions

Refer to our help wanted page – before opening a PR, we recommend asking in the issue whether help is still needed.

Package development corner

Some useful tips for R package developers. 👀

A new R core member!

The R Foundation announced that Heather Turner has joined the R Core Team! 🎉

How to browse the R mailing lists

The official mailing lists of the R project like R-package-devel are full of important and useful information. How to browse them, given that the default website is not easy to search? You can use the mail-archive website (thanks to Hugo Gruson for the reminder!) or a new project by James Balamuta: the R Mailing Lists Archive!

“Claude Code: Setting up ast-grep with R support”

Thanks to Mauro Lepore for sharing this blog post by Emil Hvitfeldt: “Claude Code: Setting up ast-grep with R support”. ast-grep is a tool for querying code by syntax rather than brittle regular expressions. The blog post describes how to add R support to this tool, and how to take advantage of it when using Claude.

On muffling messages from packages

A follow-up on our post “Please Shut Up! Verbosity Control in Packages”.

With the {cli} R package you can change the default handler for messages. See the docs. It seems mostly used to muffle messages, e.g. in flir.
Here’s how the usethis R package muffles gert message selectively.

Last words

Thanks for reading! If you want to get involved with rOpenSci, check out our Contributing Guide that can help direct you to the right place, whether you want to make code contributions, non-code contributions, or contribute in other ways like sharing use cases. You can also support our work through donations.

If you haven’t subscribed to our newsletter yet, you can do so via a form. Until it’s time for our next newsletter, you can keep in touch with us via our website and Mastodon account.

Breaking Release of the patentsview R Package

rOpenSci — Tue, 10 Mar 2026 00:00:00 +0000

The patentsview R package was created by Chris Baker to simplify interactions with the PatentsView API as announced in Chris’ blog post in 2017. The API can be queried for data from US patents granted since 1976 as well as patent applications since 2001 (not all going on to become granted patents).
As shown in the package’s vignettes, location data can be mapped, charts of assignees can be created etc. using other R packages, only limited by the developer’s imagination.

Fast-forwarding to today finds us in a precarious position as the PatentsView API team had made breaking changes and obsoleted the original API (all calls to the original endpoints return 410 Gone). As such we have spent some time now updating patentsview to work with these API changes. The updated patentsview package is now on CRAN but, unfortunately, as this Tech Note was being prepared the PatentsView API team made troubling changes.

In late February they replaced their forum with a message saying the page was temporarily unavailable. Further, they have also removed the link to request an API key, so it’s unclear whether they’d honor requests for API keys using the link below. Nothing has been officially announced but the long term viability of the API seems uncertain.

🍴 Here you’ve come to a fork (and knife) in the road, continue reading if you are/were using the original version of the patentsview package, and we’ll guide you through the necessary changes. If you have an interest in US patent data but haven’t used the patentsview package yet (and are willing to take the risk!), check out the vignette reworked from Chris’ original blog post to use the new version of the R package and API.

New changes to the API:

Users will need to request an API key and set an environmental variable PATENTSVIEW_API_KEY to this value.
Endpoint changes:
- The nber_subcategories, one of the original seven endpoints, was removed
- cpc_subsections is now cpc_group
- The remaining five original endpoints went from plural to singular, patents is now patent, for example. Interestingly, the returned data structures are still plural for the most part.
- There are now 27 endpoints, and more than one may need to be called to retrieve fields that were available from a single call to one of the original endpoints
- Some of the endpoints now return HATEOAS (Hypermedia as the Engine of Application State) links that can be called to retrieve additional data
Some fields are now nested and need to be fully qualified when used in a query, for instance, search_pv('{"cpc_current.cpc_group_id":"A01B1/00"}') when using the patent endpoint. In the fields parameter, nested fields can be fully qualified or a new API shorthand can be used, which allows you to specify group names. When group names are used, all of the group’s nested fields will be returned. For example, defining fields = c("assignees") when using the patent endpoint means that all nested assignees’ fields will be returned by the API.
Some field names have changed, most significantly, patent_number is now patent_id, and some fields were removed entirely, for instance, rawinventor_first_name and rawinventor_last_name.
The original version of the API had queryable fields and additional fields which could be retrieved but couldn’t be part of a conditional query. That notion does not apply to the new version of the API as all fields are now queryable. You may be able to simplify your code if you found yourself doing post processing on returned data because a field you were interested in was not queryable.
Now there isn’t supposed to be a difference between operators used on strings vs full text fields, as there was in the original version of the API. See the tip below the Syntax section.
Result set paging has changed significantly. This only matter to users implementing their own paging, as the package continues to handle result set paging with search_pv()’s all_pages = TRUE. There is a new Result set paging vignette to explain the API’s paging, using the size and after parameters rather than page and per_page.
Result set sizes are seemingly unbounded now. The original version of the API capped result sets at 100,000 rows.

The API team also renamed the API, PatentsView’s Search API is now the PatentSearch API. Note that the R package will retain its name, continue to use library(patentsview) to load the package.

New changes to the R package:

Throttling is now enforced by the API and handled by the R package (sleep as specified by the throttle response before a retry)
There are five new vignettes
- API Changes
- Converting an existing script
- Result set paging, should custom paging be needed
- Understanding the API, the API team’s jupyter notebook converted to R and enhanced
- Accessing patent data with the patentsview package, the blog post that announced the original version of the R package has been updated to work with the new version of the API
The R package changed internally from using httr to httr2. This only affects users if they passed additional arguments (...) to search_pv(). Previously if they passed config = httr::timeout(40) they’d now pass timeout = 40 (name-value pairs of valid curl options, as found in curl::curl_options() see req_options)
Now that the R package is using httr2, users can make use of its last_request() method to see what was sent to the API. This could be useful when trying to fix an invalid request. Also fun would be seeing the raw API response.

httr2::last_request()
httr2::last_response()
httr2::last_response() |> httr2::resp_body_json()

A new function was added retrieve_linked_data() to retrieve data from a HATEOAS link the API sent back, retrying if throttled
An existing function was removed. With the API changes, there is less of a need for cast_pv_data() which was previously part of the R package. The API now returns most fields as appropriate types, boolean, numeric etc., instead of always returning strings.

Online API documentation

The PatentsView API team has thoughtfully provided a Swagger UI page for the new version of the API at https://search.patentsview.org/swagger-ui/. Think of it as an online version of Postman already loaded with the API’s new endpoints and returns. The Swagger UI page documents what fields are returned by each endpoint on a successful call (http response code 200). You can even send in requests and see actual API responses if you enter your API key and press an endpoint’s “Try it out” and “Execute” buttons. Even error responses can be informative, the API’s X-Status-Reason response header usually points out what went wrong.

In a similar format, the updated API documentation lists what each endpoint does. Additionally, the R package’s fieldsdf data frame has been updated, now listing the new set of endpoints and fields that can be queried and/or returned. The R package’s reference pages have also been updated.

Final thoughts

As shown in the updated Top Assignees vignette, there will be occasions now where multiple API calls are needed to retrieve the same data as in a single API call in the original version of the API and R package. Additionally, the reworked rOpenSci post explains what changes had to be made since assignee latitude and longitude are no longer available from the patent endpoint.

Issues for the R package can be raised in the patentsview repo.

As we mentioned at the start, the future of the PatentsView API is a bit uncertain. PatentsView is funded by the USPTO, who may be looking to cut costs. However, until we know for certain, we hope patentsview serves you well. If nothing else, it’s been a great run, starting in 2015 for the API and 2017 for the R package!

rOpenSci Dev Guide 1.0.0: Trilingual and Improved

rOpenSci — Mon, 02 Mar 2026 00:00:00 +0000

Read it in: Español.

Read it in: Português.

rOpenSci Software Peer Review’s guidance is gathered in an online book that keeps improving! This blog post summarises what’s new in our Dev Guide 1.0.0, with all changes listed in the changelog.

Now available in Portuguese!

Our guide is now trilingual (English, Spanish, Portuguese)!

Find more about the awesome Portuguese translation project, initiated and powered by our Lusophone members in our blog post.

The translation project and ongoing multilingual maintenance uses our babelquarto package to render multilingual Quarto books and websites. It was recently peer-reviewed by Ella Kaye and João Granja-Correia.

We’re actively working on our babeldown package to create and update translations using the DeepL API.

In the dev guide itself, tools useful for internationalizing packages are mentioned: potools, the experimental rhelpi18n package, selecting a language for a pkgdown website.

Policy Updates

We made some changes to rOpenSci policies and scope:

New category for rOpenSci internal and peer-review tools.
Updates to the data retrieval category.
New explicit rule to only submit one package at a time.
New requirement to not call the default branch “master”.
Removed requirement to use a codemeta.json file, now deprecated. Codemeta continues to be actively used and developed, but we have found it redundant with other metadata and Codemeta can generate these data as-needed from DESCRIPTION files.

Editor Guide, Author Guide & Reviewer Guide

The guides that live in our guide. 😸

The whole editor guide was has been restructured to follow the typical flow of submissions, and to better explain how to use the software-review dashboard. We added a section on challenges, and documented how to put the system on vacation (which we generally do over the new year period).

Likewise, we improved the organization and content of the author guide (thanks to Alec Robitaille and Joan Maspons).

In the reviewer guide, we removed the external link to the no-longer maintained Mozilla Review guide (one of our early design sources for peer-review) in favor of explicit enumerated items.

Packaging Best Practices

In the packaging guide (another guide within the guide!), we added guidance for choosing example datasets. Furthermore, we created a section for Packages wrapping external software. The licencing section now explicitly requires acknowledging authors of bundled code. Last but not least, the section about dependencies recommends checking the development status of dependencies.

The whole book now mentions the Air CLI every time it mentions the styler package, as Air can be viewed as styler’s successor.

In the chapter about Package evolution, we added guidance on deprecating data, and explained the drawbacks of renaming a widely-used package.

Testing guidance

We updated our testing guidance with

a mention of tinytest as an alternative to testthat;
a note on keeping tests written with testthat self-contained.

Package Documentation

With particular thanks to Alasdair Warwick , we improved the documentation 😉 of our documentation building system, including:

More details on the technical aspects of docs building for rOpenSci packages;
Updated math guidance following pkgdown’s update.

We also clarified different strategies to document internal functions, thanks to Claudiu Forgaci.

Metadata & Package Information

We documented more ways to acknowledge contributors:

in the authorship section of the packaging guide, with Research Organization Registry (ROR) IDs;
in the chapter about collaboration, the allcontributors R package.

Conclusion

In this post we summarized the changes in the latest version of our book “rOpenSci Packages: Development, Maintenance, and Peer Review”. We are thankful for all contributions that created this release. We are already working on the next version. Don’t hesitate to help us shape it by opening an issue!

Software Review in the Era of AI: What We Are Testing at rOpenSci

rOpenSci — Thu, 26 Feb 2026 00:00:00 +0000

The advent of large language models (LLMs) and generative AI tools has changed the nature of software development and of software review. These developments are complex, challenging, and controversial, but require action to maintain and grow rOpenSci’s programs and community. In response, we are starting with a preliminary set of policies to clarify our expectations for use of generative AI tools by authors, reviewers, and editors in software peer-review. This blog post describes the challenges ahead and initial changes we are making.

Challenge: Maintaining our core values

Our top challenge is maintaining our core values.

A central value for rOpenSci is fostering a welcoming community, in particular through supporting and encouraging people who might otherwise feel excluded. Generative AI tools can help with that. Large language models and generative AI tools may make many coding tasks easier and quicker, and can expand the community of people able to contribute to open source software and the OSS community.

Yet there are many downsides to generative AI tools which challenge our core values. pyOpenSci has done an excellent job exploring these in this blog post. They fall into two broad areas.

First, use of AI can in many cases degrade the quality of both open-source scientific code and the process by which we create it. LLMs can in many cases produce incorrect outputs, fail to generate time or efficiency benefits, or degrade the process of learning to code or the social cohesion of the community. A core design of our software peer-review is to drive community building through healthy interactions between authors, reviewers, and contributors. We aim to improve and promote the quality of research software, to facilitate good development practices among researchers, to foster collaboration, and to curate a community of practice. Any use of AI must be compatible with that goal.

Second, AI has the potential for tremendous broader impacts or externalities: environmental impacts, amplification of bias, infringement of creative and intellectual rights, or even driving increases in social and economic inequality. We have both collective and individual responsibilities to address these impacts, which include the right to opt out of uses of AI.

Challenge: Changing the focus of software reviews

Editors and reviewers at rOpenSci are volunteers who devote their own time to help others improve the quality of their software. Our review system works because they have always been able to assume that all aspects of code submitted for review have reflected decisions made by the human authors of software. That, in turn, has ensured that the efforts of editors and reviewers are proportional to the primary efforts of software authors.

Generative AI tools potentially change both of these situations. They enable software to be produced with relatively little human input or oversight, which means editors and reviewers may put more consideration into software design, structure, and function than submitting authors. We do not want software review to become a service in which our human volunteers validate largely AI-generated software. That would put at risk the equal and constructive interaction of review, and likely reduce the motivation of editors and reviewers. We need to ensure that our software review process remains focused on the decisions, designs, and implementations of the submitting authors.

One option is requesting authors to outline the areas that have been AI generated, and specifying the scope of their own work. However, this could result in our previously holistic process becoming one where only defined aspects or sections of software end up being reviewed. Authors declaring that a certain tool was used to generate all tests may lead one reviewer to completely ignore those tests, while another reviewer may be passionately engaged in the ways by which exactly that tool writes tests.

In any case, this will require everybody to be as open as possible about what, where, and how generative AI tools may have been used.

Response: Preliminary policies

Our initial policy updates are not intended to restrict use of generative AI tools, but to encourage the rOpenSci community to approach these tools in ways that encourage, rather than diminish, healthy community interactions.

Similar updates have already been implemented by both the Journal of Open Source Software and pyOpenSci, and we are indebted to the work of all those who contributed to these policy statements.

Importantly, our software review policies and practices have evolved over many years in response to community engagement and feedback. The introduction of policies addressing generative AI tools is a part of that evolution, and these policies will also evolve further in responses to community engagement, and changing community practices.

No change in scope

One potential response would be a change in the scope of packages we review. JOSS has updated their scope definition to, among other things, require a longer record of continuous development, along with other criteria, such as evidence of impact and design. At rOpenSci, authors often seek feedback on early-stage software. Our review process commonly involves deep and broad consideration through extensive exchanges between authors, reviewers, and editors. We are confident that this extends to many of the areas emphasized by JOSS’s updated criteria, and we therefore see no need to explicitly change either the scope or focus of review.

Requiring openness of AI usage

Our policy updates aim to retain the same degree of openness and transparency we have always practiced, while extending to the new area of generative AI tools and practices. We cannot know the eventual impact that generative AI tools may have on software review processes and practices at rOpenSci, and can ask only for an utmost degree of transparency from all involved.

We now describe specific updates to both our practices and policies for authors, for editors, and for reviewers. Software review aims to provide authors with feedback on their practices and choices, and not just on the lines of code they or an AI generated. We also value the time and effort of editors and reviewers, and want them to be able to focus on the practices and choices of authors.

Practical application: for authors

Authors who do not use generative AI tools will submit as always, with no extra requirements. Those who do use such tools will be asked to describe their use, and to affirm that all generated material has been carefully reviewed by the authors. We want these descriptions to help reviewers and editors to understand how they can best review code and provide useful feedback.

We will be modifying our submission template to include this required section, and will be updating the Guide for Authors with additional guidance.

A minimal example might be a statement that “we’re not very proficient in C, so we used an LLM to generate most of the code for the C algorithm.” This might guide reviewers to pay particular attention to the tests for that part of the package. A more extensive description might be that, “We used <tool-of-choice> to generate all tests, but have read, edited, and manually stepped through each test ourselves.” This can help reviewers decide whether to pay more or less attention to the tests depending on their interests. Either way, knowing that tests were generated by AI tools is useful and important to the review process.

Descriptions may refer to relevant documentation in the repository, such as:

Design documents which highlight key components and explain their design;
“agents.md” or equivalent files, along with explanations of how these have been used, along with clear description of the roles of the submitting authors;
Overviews of developmental histories, for example in “NEWS.md” or equivalent files.

We intend to maintain our requirement for “CONTRIBUTING.md” files, as any generative AI tools can also be directed to treat that as an “agents.md” file.

This is our intended addition to the templates for authors submitting software for review:

## Use of Generative AI
- [ ] Generative AI tools were used to produce some of the material in this submission.
If so, please describe: <!-- refer to our AI policies at http:// ... -->
If your repository includes an "agents.md" file or equivalent, please provide a link, and describe how this has been used in the development of your package.

An example of such a description can be found in this recent software review submission.

Practical application: for editors

Editors are the first to view software submitted to rOpenSci, and generally complete an initial Editors checklist indicating whether they think a package may proceed to review. This checklist will also include an additional item:

- [ ] **Use of generative AI tools**: If the authors have used generative AI tools, have they sufficiently described their usage?

This item will also require no additional action by editors unless authors have used generative AI tools.

Initial editorial considerations have until now been largely technical, including many of the aspects now automated by our pkgcheck system. In response to this new checklist item, editors may broaden their consideration to whether a package has had sufficient human contribution to be worth reviewing, alongside considerations of additional factors such as:

Clear statements of package motivation and importance.
Package development history.
Evidence of design decisions motivating the software.

When recruiting reviewers for a package, editors may describe authors’ AI usage where relevant to help them understand the nature of the package and demands of review.

Practical application: for reviewers

Review processes at rOpenSci frequently involve reviewers recommending potential improvements, and authors then implementing those. In adapting to use of generative AI tools, we will strive to maintain the same culture of constructive feedback. We hope that authors will provide sufficient information on any use of generative AI tools to guide reviewers towards aspects of their software requiring particular attention.

Reviewers are permitted to use generative AI tools in preparing reviews for rOpenSci, but their use must meet the same criteria of supporting the goals of review. Our Guide for Reviewers will be updated to note the following points:

Generative AI tools may be used to aid the review process, but all review text must reflect the judgement of the reviewer.
Typical and acceptable use of generative AI tools in software review includes getting an overview of software design, structure, and function.

Updates to the Guide for Reviewers will also include examples of productive use of generative AI tools in the review process. We aim to run pilots over the course of this year to test where in the review process AI can best be used to improve everyone’s experience, and to provide more robust guidelines and custom tools.

Reviewers may also consider AI use in choosing whether to volunteer as a reviewer of a package, and authors should be aware that extensive AI use could increase the time to find reviewers.

Moving forward

This is our first pass at providing guidelines governing the use of generative AI to ensure rOpenSci software review continues to improve while retaining its essential values.

With more package submissions having some component of AI contribution, the editorial board thought it essential to provide these updates to manage the process as we learn more about what works and what does not.

We invite you to further discuss the evolving role of AI in software review in this issue, and more importantly to join us as an author or reviewer in peer review, so we can learn together!