More work on vignettes

man.Rmd

@@ -753,7 +753,7 @@ For the initial CRAN submission of your package, all functions must have at leas
 If the code can only be run under specific conditions, use the techniques below to express those pre-conditions.
 :::
 
-### Dependencies and conditional execution
+### Dependencies and conditional execution {#sec-man-examples-dependencies-conditional-execution}
 
 An additional source of errors in examples is the use of external dependencies: you can only use packages in your examples that your package formally depends on (i.e. that appear in `Imports` or `Suggests`).
 Furthermore, example code is run in the user's environment, not the package environment, so you'll have to either explicitly attach the dependency with `library()` or refer to each function with `::`.

structure.Rmd

@@ -59,7 +59,7 @@ Examples:
 Note that exploring a package's source and history within the `cran` GitHub organisation is not the same as exploring the package's true development venue, because this source and its evolution is just reverse-engineered from the package's CRAN releases.
 This presents a redacted view of the package and its history, but, by definition, it includes everything that is essential.
 
-## Bundled package
+## Bundled package {#sec-bundled-package}
 
 A **bundled** package is a package that's been compressed into a single file.
 By convention (from Linux), package bundles in R use the extension `.tar.gz` and are sometimes referred to as "source tarballs".

testing-design.Rmd

@@ -57,7 +57,7 @@ We use covr regularly, in two different ways:
 -   Local, interactive use. We mostly use `devtools::test_coverage_active_file()` and `devtools::test_coverage()`, for exploring the coverage of an individual file or the whole package, respectively.
 -   Automatic, remote use via GitHub Actions (GHA). We cover continuous integration and GHA more thoroughly elsewhere, but we will at least mention here that `usethis::use_github_action("test-coverage")` configures a GHA workflow that constantly monitors your test coverage. Test coverage can be an especially helpful metric when evaluating a pull request (either your own or from an external contributor). A proposed change that is well-covered by tests is less risky to merge.
 
-## High-level principles for testing
+## High-level principles for testing {#sec-testing-design-principles}
 
 In later sections, we offer concrete strategies for how to handle common testing dilemmas in R.
 Here we lay out the high-level principles that underpin these recommendations: