Convert to quarto (#232)

* Rename to .qmd
* Convert to quarto rendering
* Update GHA
* Update cross references
* Globally disable evaluation

.github/workflows/bookdown.yaml → .github/workflows/quarto.yaml

@@ -2,13 +2,12 @@ on:
   push:
     branches: [main, master]
   pull_request:
-    branches: [main, master]
   workflow_dispatch:
 
-name: bookdown
+name: quarto.yml
 
 jobs:
-  build:
+  quarto:
     runs-on: ubuntu-latest
     env:
       GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
@@ -21,19 +20,11 @@ jobs:
 
       - uses: r-lib/actions/setup-r-dependencies@v2
 
-      - uses: r-lib/actions/setup-pandoc@v2
-
-      - name: Cache bookdown results
-        uses: actions/cache@v2
-        with:
-          path: _bookdown_files
-          key: bookdown-${{ hashFiles('**/*Rmd') }}
-          restore-keys: bookdown-
+      - name: Install Quarto
+        uses: quarto-dev/quarto-actions/install-quarto@v1
 
-      - name: Build site
-        run: |
-          bookdown::render_book('index.Rmd', 'bookdown::bs4_book', quiet = TRUE)
-        shell: Rscript {0}
+      - name: Render book
+        run: quarto render
 
       - name: Deploy to GitHub pages 🚀
         if: github.event_name != 'pull_request'

_quarto.yml

@@ -0,0 +1,45 @@
+project:
+  type: book
+
+book:
+  title: Tidyverse style guide
+  author: The tidyverse team
+
+  site-url: https://style.tidyverse.org
+  repo-url: https://github.com/tidyverse/style/
+  repo-branch: main
+  repo-actions: [edit, issue]
+
+  chapters:
+  - index.qmd
+
+  - part: Analyses
+    chapters:
+    - files.qmd
+    - syntax.qmd
+    - functions.qmd
+    - pipes.qmd
+    - ggplot2.qmd
+
+  - part: Packages
+    chapters:
+    - package-files.qmd
+    - documentation.qmd
+    - tests.qmd
+    - errors.qmd
+    - news.qmd
+
+  - part: Other
+    chapters:
+    - git.qmd
+
+format:
+  html:
+    include-in-header: "plausible.html"
+    callout-appearance: simple
+    theme:
+      - styles.scss
+
+knitr:
+  opts_chunk:
+    eval: false

documentation.Rmd → documentation.qmd

@@ -1,4 +1,4 @@
-# Documentation
+# Documentation {#sec-documentation}
 
 ## Introduction
 
@@ -7,10 +7,6 @@ is future-you. Use [roxygen2](https://github.com/klutometis/roxygen) with
 [markdown](https://github.com/klutometis/roxygen/blob/master/vignettes/markdown.Rmd)
 support enabled to keep your documentation close to the code.
 
-```{r, include=FALSE}
-knitr::opts_chunk$set(eval = FALSE)
-```
-
 ## Title and description
 
 Use the first line of your function documentation to provide a concise title that describes the function, dataset, or class. Titles should use sentence case

errors.Rmd → errors.qmd

@@ -1,9 +1,5 @@
 # Error messages
 
-```{r, include = FALSE}
-knitr::opts_chunk$set(eval = FALSE)
-```
-
 An error message should start with a general statement of the problem then give a concise description of what went wrong.
 Consistent use of punctuation and formatting makes errors easier to parse.
 

files.Rmd → files.qmd

@@ -1,4 +1,4 @@
-# Files
+# Files {#sec-files}
 
 ## Names
 
@@ -43,7 +43,7 @@ It's hard to describe exactly how you should organise your code across multiple
 Use commented lines of `-` and `=` to break up your file into easily readable
 chunks.
 
-```{r, eval = FALSE}
+```{r}
 # Load data ---------------------------
 
 # Plot data ---------------------------

functions.Rmd → functions.qmd

@@ -4,7 +4,7 @@
 
 As well as following the general advice for [object names], strive to use verbs for function names:
 
-```{r eval = FALSE}
+```{r}
 # Good
 add_row()
 permute()
@@ -62,7 +62,7 @@ There are two options if the function name and definition can't fit on a single
 *   **Single-indent**: indent the argument name with a single indent (i.e. two spaces).
     The trailing `)` and leading `{` go on a new line.
 
-    ```{r, eval = FALSE}
+    ```{r}
     # Good
     long_function_name <- function(
       a = "a long argument",
@@ -76,7 +76,7 @@ There are two options if the function name and definition can't fit on a single
 *   **Hanging-indent**: indent the argument name to match the opening `(` of `function`.
     The trailing `)` and leading `{` go on the same line as the last argument.
 
-    ```{r, eval = FALSE}
+    ```{r}
     # Good
     long_function_name <- function(a = "a long argument",
                                    b = "another argument",
@@ -87,7 +87,7 @@ There are two options if the function name and definition can't fit on a single
 
 These styles are designed to clearly separate the function definition from its body.
 
-```{r, eval = FALSE}
+```{r}
 # Bad
 long_function_name <- function(a = "a long argument",
   b = "another argument",
@@ -103,7 +103,7 @@ If a function argument can't fit on a single line, this is a sign you should rew
 
 In S7, the method definition can be long because the function name is replaced by a method call that specifies the generic and dispatch classes. In this case we recommend the single-indent style.
 
-```{r, eval = FALSE}
+```{r}
 method(from_provider, list(openai_provider, class_any)) <- function(
   provider,
   x,
@@ -117,7 +117,7 @@ method(from_provider, list(openai_provider, class_any)) <- function(
 If the method definition is too long to fit on one line, use the usual rules to
 spread the method arguments across multiple lines:
 
-```{r, eval = FALSE}
+```{r}
 method(
   from_provider,
   list(openai_provider, class_any, a_very_long_class_name)
@@ -136,7 +136,7 @@ method(
 Only use `return()` for early returns. Otherwise, rely on R to return the result
 of the last evaluated expression.
 
-```{r eval = FALSE}
+```{r}
 # Good
 find_abs <- function(x) {
   if (x > 0) {
@@ -156,7 +156,7 @@ add_two <- function(x, y) {
 
 Return statements should always be on their own line because they have important effects on the control flow. See also [inline statements](#inline-statements).
 
-```{r, eval = FALSE}
+```{r}
 # Good
 find_abs <- function(x) {
   if (x > 0) {
@@ -177,7 +177,7 @@ plotting, or saving to disk), it should return the first argument invisibly.
 This makes it possible to use the function as part of a pipe. `print` methods
 should usually do this, like this example from [httr](http://httr.r-lib.org/):
 
-```{r eval = FALSE}
+```{r}
 print.url <- function(x, ...) {
   cat("Url: ", build_url(x), "\n", sep = "")
   invisible(x)
@@ -189,7 +189,7 @@ print.url <- function(x, ...) {
 In code, use comments to explain the "why" not the "what" or "how". Each line
 of a comment should begin with the comment symbol and a single space: `# `.
 
-```{r, eval = FALSE}
+```{r}
 # Good
 
 # Objects like data frames are treated as leaves
@@ -205,7 +205,7 @@ x <- map_if(x, is_bare_list, recurse)
 Comments should be in sentence case, and only end with a full stop if they
 contain at least two sentences:
 
-```{r, eval = FALSE}
+```{r}
 # Good
 
 # Objects like data frames are treated as leaves

ggplot2.Rmd → ggplot2.qmd

@@ -12,7 +12,7 @@ Styling suggestions for `+` used to separate ggplot2 layers are very similar to
 
 If you are creating a ggplot off of a dplyr pipeline, there should only be one level of indentation.
 
-```{r eval=FALSE}
+```{r}
 # Good
 iris |>
   filter(Species == "setosa") |>
@@ -36,7 +36,7 @@ iris |>
 
 If the arguments to a ggplot2 layer don't all fit on one line, put each argument on its own line and indent:
 
-```{r, eval = FALSE}
+```{r}
 # Good
 ggplot(aes(x = Sepal.Width, y = Sepal.Length, color = Species)) +
   geom_point() +
@@ -54,7 +54,7 @@ ggplot(aes(x = Sepal.Width, y = Sepal.Length, color = Species)) +
 
 ggplot2 allows you to do data manipulation, such as filtering or slicing, within the `data` argument. Avoid this, and instead do the data manipulation in a pipeline before starting plotting.
 
-```{r eval=FALSE}
+```{r}
 # Good
 iris |>
   filter(Species == "setosa") |>

index.Rmd → index.qmd

@@ -1,12 +1,3 @@
----
-title: "The tidyverse style guide"
-author: ["Hadley Wickham"]
-site: bookdown::bookdown_site
-output: bookdown::bs4_book
-github-repo: tidyverse/style
-documentclass: book
----
-
 # Welcome {-}
 
 Good coding style is like correct punctuation: you can manage without it, butitsuremakesthingseasiertoread. This site describes the style used throughout the [tidyverse](http://tidyverse.org). It was derived from Google's original R Style Guide - but
@@ -20,7 +11,10 @@ Two R packages support this style guide:
     selected text, files, or entire projects. It includes an RStudio add-in,
     the easiest way to re-style existing code.
 
-    ```{r, echo = FALSE, fig.align = "center"}
+    ```{r}
+    #| eval: true
+    #| echo: false
+    #| fig-align: center
     knitr::include_graphics("styler-addin.png", dpi = 220)
     ```
 

news.Rmd → news.qmd

@@ -6,7 +6,7 @@ Each user-facing change to a package should be accompanied by a bullet in `NEWS.
 
 The goal of the bullet is to briefly describe the change so users of the packages can understand what's changed. This can be similar to the commit message, but written with a user (not developer) in mind. It's worth emphasizing this point --- the reader of your NEWS entries is likely unfamiliar with the day-to-day development work or internals of your package. Think carefully about how to concisely but clearly summarize what's changed and why it matters for them. If it doesn't matter (i.e. it's a purely internal change), you don't need a bullet.
 
-New bullets should be added to the top of the file (immediately under the first heading) and should be a single line. Organisation and wrapping will happen later, during the release process (Section \@ref(news-release)).
+New bullets should be added to the top of the file (immediately under the first heading) and should be a single line. Organisation and wrapping will happen later, during the release process.
 
 ```
 # haven (development version)

package-files.Rmd → package-files.qmd

@@ -1,6 +1,6 @@
 # Files {#package-files}
 
-The majority of advice in Chapter \@ref(files) also applies to files in packages. Important differences are described below.
+The majority of advice in @sec-files also applies to files in packages. Important differences are described below.
 
 ## Names
 
@@ -19,7 +19,7 @@ documentation should appear first, with private functions appearing after all
 documented functions. If multiple public functions share the same documentation,
 they should all immediately follow the documentation block.
 
-See \@ref(documentation) for more thorough guidance on documenting functions
+See @sec-documentation for more thorough guidance on documenting functions
 in packages.
 
 ```{r}