pkgdown build_site example not rendering

I have the following as an example in two files

@examples
x <- mtcars$mpg

some_func_here(x)

The some_func_here(x) is failing because it says that x is not found...

Here are the two pages where the example fails: bootstrap_p_augment AND bootstrap_p_vec

Here are examples where x the same x works ci_hi

So I am not understanding why it is failing, nor do I even know where to start looking.

Solution

As discussed in the comments, there is a bug in the bootstrap_p_vec function. It has an argument .x, but it checked whether x was numeric. See https://github.com/spsanderson/TidyDensity/blob/a101d7568fbae0a883e7dfaf960236f98cb59fe8/R/vec-bootstrap-p.R#L34 .

In functions in packages, the search order for variables is as follows:

first look for local variables (including arguments) matching the name. This would fail because of the typo.
next look in the environment of the function, i.e. the package environment. There is no x defined there so this also fails.
next look through the imports declared for the package. This also fails.
next look in the base package, which is implicitly imported. No x there.
finally, go through the user's search list, starting with the global environment, and checking all attached packages. Your bad code found the x in the global environment, so you didn't get the error you should have got in normal runs.

If you had named the global variable xnew and didn't have some other variable called x lying around, you would have got the error even in normal runs.

When pkgdown::build_site() runs your code, it doesn't follow the same rules. It sets up a fake global environment, and never puts that in the search list. Effectively this means it skips the last step above, so it never finds x. In my opinion, this is a better way to do variable searches, because users sometimes have total junk in their global environment, and you don't want a typo to find that and work with it. You want typos to cause immediate failures.

If you ran R CMD check on your package, you should have seen a warning that bootstrap_p_vec uses the global x. Except you won't see that, because you have suppressed this warning by declaring x within 00_global_variables.R, effectively saying that everything is okay (even though it wasn't).

Unfortunately, code in the tidyverse gets a huge number of false positive warnings about globals, so tidyverse code almost has no choice but to suppress this error. They should have stuck with standard evaluation, and then you wouldn't have this insidious bug in your code.