Silence CRAN codetools NOTEs for globals 'id' and 'location' using rlang

[Smit-tay]

Silence CRAN codetools NOTEs for globals 'id' and 'location' using rlang

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
R/project_visualiser.R	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Smit-tay]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
R/project_visualiser.R 0.00% 1 Missing ⚠️
📢 Thoughts on this report? Let us know!

No idea what this is trying to communicate

[Smit-tay]

Since it wasn't clear why this is a problem, I asked Grok. This is the explanation, and this explains my PR changes.

What the NOTEs say

The message is:
find_function_calls_in_folder: no visible binding for global variable ‘location’
processNodes: no visible binding for global variable ‘id’
Undefined global functions or variables:
id location

This is a very common NOTE in R packages. It means the static code analysis in R CMD check cannot see where the variables id and location are defined — even though they probably are defined correctly at runtime.

Most likely causes (and fixes)
This pattern usually happens in one of these situations:

Non-standard evaluation (NSE) / tidy-evaluation style code
You are probably using rlang/tidyselect/dplyr/ggplot2-like syntax where you pass bare column names (id, location) inside functions like dplyr::select(), ggplot(aes()), rlang::sym(), data masking, etc.
→ R CMD check cannot statically see that these are column names, not globals.

Fix (preferred modern way):

#' @importFrom rlang .data
NULL
Then inside your functions use .data$id and .data$location (or .data[["id"]], etc.).

This tells check that these are intentional data-pronoun references and silences the NOTE cleanly without .GlobalEnv hacks.

Dynamically created variables or eval(parse()) / metaprogramming
If you're building expressions or using get() / eval() / parse() involving those names → same issue.

Fix:
use the .data$ approach above if it's tidy-eval, or @global id location in roxygen if you really mean globals (rarely recommended).
Missing @importFrom or @import
Less likely here since the names are very generic, but worth checking if they're supposed to come from another package.

[RobertASmith]

I think this solves the issue. @W-Mohammed once you are happy feel free to re-submit to CRAN.

[W-Mohammed]

Fixed in #142. Closing PR as is now redundant.