easystats: a family of R packages for models, effect sizes and reporting

A meta-package that admits it has no single way

The README is unusually honest about what easystats is and is not, and the first statement sets the tone. It is a collection of R packages aiming to provide a unifying and consistent framework to tame, discipline and harness the scary R statistics and their pesky models. Then comes the qualification: there is not, yet, a unique easystats way of doing data analysis. Instead, the advice is to start with one package and, when you face a new challenge, check whether there is an easystats answer for it in another package.

That framing matters because a meta-package is easy to mistake for a framework with a unified API. The easystats meta-package gives you access to the entire ecosystem and its consistent design principles without needing to know the specific package of each function, but the consistency is at the level of conventions, arguments and output classes, not at the level of one pipeline.

The Statement of Need section explains the problem it is aimed at. R is a powerful language for statistical computing, but its capabilities are scattered across a fragmented landscape of packages, and a full analysis involving data manipulation, modelling, diagnostics, interpretation and visualisation often means juggling multiple tools with different syntax, design principles, outputs and classes. The claim is that this creates barriers for newcomers and inefficiencies even for experienced users. The stated response is a workflow from data exploration to result communication, with defaults and documentation that push towards reproducible and transparent practice.

The primary language is R, the licence is listed as a custom one that GitHub cannot classify with a LICENSE file, and the homepage is the pkgdown site at easystats.github.io/easystats. The repository is not archived and the last push was on 2026-10-19, with the most recent release easystats 0.7.5 from 2025-07-11.

The ten packages and the stage of the analysis each one covers

The package list is best read as a map of the stages of a statistical analysis, which is the clearest way to understand why the collection exists.

For getting data ready, datawizard handles cleaning and transformation. For the model itself, the ecosystem's own tools are used alongside base R, and insight is the package for developers that helps work with different models and packages.

For reading the model, parameters produces a table containing all information about the parameters of your models, performance gives the quality and performance metrics of models, R2, ICC, LOO, AIC, BF and the rest, and effectsize computes, converts, interprets and works with indices of effect size and standardized parameters. modelbased estimates effects, group averages and contrasts between groups based on statistical models, and bayestestR covers Bayesian statistics, described as good for beginners or experts. correlation is the all-in-one package to run correlations.

For communicating, see is the plotting companion for results visualizations, and report does automated statistical reporting of objects in R, producing the written output of an analysis rather than just numbers.

That coverage is what makes the meta-package convenient. The workflow the README describes is that you explore the packages, pick the ones that fit, and as you use more of them the workflow becomes smooth because they are meant to work together. The FAQ in the README makes the same point about the tidyverse comparison, and the answer there is emphatic: pick both. The distinction drawn is that the tidyverse packages focus on making data manipulation and exploration intuitive and consistent, while easystats focuses on the final stretch of the analysis, the modelling and reporting side.

That boundary is the thing to hold on to. If your pain is reshaping a data frame, easystats is not the answer. If your pain is that the output of your model is an object you cannot easily turn into a table of effect sizes or a paragraph for a report, it is.

Installing: CRAN, the r-universe dev build, or GitHub

The installation table in the README gives three routes, and the choice between them is a real decision rather than a formality.

install.packages("easystats")

That is the CRAN release. The development versions come either from the project's own r-universe repository:

install.packages("easystats", repos = "https://easystats.r-universe.dev")

or straight from GitHub with remotes::install_github("easystats/easystats"). The r-universe route is the interesting one, because it is a package repository the project runs itself, which means you get the whole ecosystem's development versions from a single source rather than mixing CRAN releases of some packages with GitHub installs of others. The README carries an insight status badge pointing at that universe, and a separate r-universe badge for the meta-package itself.

Then there is the dependency wrinkle, which the README handles in a sentence that is easy to skim past. Easystats sometimes depends on additional packages for specific functions that are not downloaded by default, and if you want the full experience without hiccups you run:

easystats::install_suggested()

This is the sort of thing that turns a smooth workflow into a broken one if you skip it. The suggested packages are the ones that power particular functions, so a fresh install can produce a package that installs cleanly and then fails at the moment you call the one function that needs the optional dependency. Running install_suggested() after the install avoids discovering that at the worst moment.

The README points at a separate article on how to cite individual packages in the ecosystem if you only use some of them, which is the detail a careful user of a meta-package will want: citing easystats wholesale when you only used two of its packages misrepresents your work, and the project has thought about how to cite at the right granularity.

insight and the modular argument, which cuts both ways

The most interesting claim in the README is about how the ecosystem relates to other packages, and it argues for a specific design philosophy rather than a marketing position.

The modular and lightweight nature of the ecosystem is said to enable developers to use and integrate in other packages only the necessary components. The example given is insight, described as a dependency-free package for retrieving model information, which is utilized by 45 other CRAN packages, such as marginaleffects and gtsummary.

That example is the interesting part. A package that is a dependency of 45 other CRAN packages is not being adopted because its author promoted it inside the easystats meta-package. It is being adopted because other package authors needed to extract model information from many different model object types and needed one implementation of that. So the argument is that the ecosystem is designed so that individual components are independently useful, and the meta-package is a convenience layer on top rather than the actual product.

The same structure explains the design of the easystats meta-package itself. It grants access to the entire ecosystem and its consistent design principles without needing to know the specific package of each function, which means the failure mode of a meta-package, a namespace full of thousands of masked names and no way to tell which package a function came from, is explicitly something the ecosystem is trying to reduce. The consistency claim in the Statement of Need rests on shared syntax and shared output classes.

There is a cost to that design, though, and it is the one worth weighing before adopting. A consistent convention across packages means a convention you have to learn, and a set of defaults that will sometimes not be the defaults you want. The README's own framing, that there is not yet a unique easystats way, is a hint that the conventions are shared but not yet total. And the dependency graph is real: with the meta-package you install the whole ecosystem, and the suggestion that some functions need additional packages means the full install is larger than a single-purpose package.

Citing the package, and what the citation says about the project

The README's citation section is worth reading, because it tells you something about how the project sees itself.

Running citation("easystats") prints a reference to the 2022 paper by Lüdecke, Patil, Ben-Shachar, Wiernik, Bacher, Thériault and Makowski, with the title easystats: Framework for Easy Statistical Modeling, Visualization, and Reporting, a CRAN doi of 10.32614/CRAN.package.easystats, and a BibTeX entry for LaTeX users with the same author list, the doi, the year and the package URL. The BibTeX block is included in full in the README, so you can copy it rather than reconstruct it.

The date on the citation is 2022 and the year field in the BibTeX is 2022, while the release history shows 0.7.3 in 2024, 0.7.4 in 2025 and 0.7.5 in July 2025. A static citation for a package that continues to be released is a known weakness of R package citation practice in general, and it is a small thing to note if you are citing version-specific work: pin the version in your own text, since the auto-generated citation does not carry it.

The citation is also the clearest statement of the project's scope. Statistical modelling, visualization and reporting, in that order, and the author list includes the people behind several of the individual packages. The paper/ directory in the repository, along with publications/ and presentations/, suggests the project maintains a record of the academic material around the ecosystem, which is unusual for a package collection and is one of the reasons the citation is stable.

The licence deserves a note. The repository listing shows both a LICENSE and a LICENSE.md file at the top level, and the repository metadata classifies the licence as a custom one that GitHub cannot categorise. The metadata also carries a Cite-Unpublished badge pointing at the inst/CITATION file, which indicates the citation metadata is maintained in the package itself rather than being generated by the repository host. For a project published on CRAN and used in academic work, the licence and citation files are the two things to read directly rather than to infer.

Where easystats does not fit

Three situations are worth naming, because the collection is popular and the boundary of its usefulness is not the same as its popularity.

The first is a single task. If you need one table of standardised parameters from one model type, installing a meta-package that pulls in ten interdependent packages to get it is a poor trade. The README's own framing supports this, since it describes starting with one package, and the ecosystem is explicitly designed so that individual packages can be used on their own. Depending on {insight} alone, or {parameters} alone, is the supported path and probably the right one.

The second is data manipulation and exploration. The README's own comparison with the tidyverse draws this line explicitly, saying the tidyverse packages are primarily made to create a new R experience where data manipulation and exploration is intuitive and consistent, while easystats focuses on the final stretch. If your bottleneck is reshaping and cleaning data before you ever fit a model, the tooling easystats provides is not aimed at that.

The third is reproducibility expectations that require one opinionated pipeline. The Statement of Need mentions nudging users towards good, reproducible and transparent statistical practices with sensible defaults, and that is a nudge rather than an enforcement. The README is candid that there is not a unique easystats way of doing data analysis. If your group's requirement is that everyone runs the same sequence of operations in the same way, with one API, this collection of packages that share conventions but not a single pipeline is going to need enforcement from you, not from the package.

There is also the ordinary R risk, which is not the project's fault but is its cost. Installing a meta-package means pulling a dependency tree of R packages from CRAN, and every one of them is a separate thing that can break, be archived, or need a newer R. The mitigations are the ones the project already provides, which are the CRAN channel for stability and the r-universe channel for a consistent set of development versions, and the CRAN-SUBMISSION file and cran-comments.md at the top level show the submission process is a maintained part of the workflow rather than an afterthought.

Editorial conclusion

Adopt easystats if you work in R on regression analyses and want one consistent syntax from fitting a model through parameters, effect sizes and performance metrics to a written report, with sensible defaults and documentation. Do not adopt it if you need a single package for a single task, since the meta-package installs the whole ecosystem, and note that easystats deliberately does not impose one way of doing analysis. Verify first that your R version satisfies the package requirements, that the specific easystats package you need is on CRAN in the version you need, and that the citation and licence terms in the DESCRIPTION and LICENSE files match what your institution requires for published work.

Frequently asked questions

Official sources

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