Apéndice A — R CMD check

R CMD check se compone de más de 50 controles individuales, que se describen en las siguientes secciones. Para cada verificación, describimos brevemente qué hace, cuáles son los problemas más comunes y cómo solucionarlos. Cuando tenga un problema con R CMD check y no sepa cómo solucionarlo, utilice esta lista para descubrir qué debe hacer. Para que sea más fácil comprender cómo encajan los cheques, los hemos organizado en secciones que corresponden aproximadamente a los capítulos de este libro. Esto significa que estarán en un orden algo diferente al que verá cuando ejecute devtools::check(), que es nuestra forma principal de ejecutar R CMD check.

Si este capítulo no coincide con lo que está viendo, considere que las comprobaciones pueden haber cambiado desde que se redactó. R continúa evolucionando, incluida la R CMD check. Quizás desee consultar la versión en línea más reciente de este capítulo: https://r-pkgs.org/r-cmd-check.html. Abra un problema si encuentra un problema con el que este capítulo no ayuda.

Al final (Sección A.12), destacamos algunas NOTAS que surgen durante la “verificación de R CMD” que no requieren ninguna respuesta por su parte. En general, recomendamos eliminar todas las NOTAS, especialmente para los paquetes destinados a CRAN, pero hay un pequeño puñado de NOTAS que realmente son informativas. Son la excepción a la regla.

A.1 Verificar metadatos

R CMD check siempre comienza describiendo tu entorno actual.

  • Using log directory ‘/some/tmp/path/googledrive.Rcheck’
  • Using R version 4.2.2 (2022-10-31)
  • Using platform: x86_64-apple-darwin17.0 (64-bit)
  • Using session charset: UTF-8

A continuación, se analiza el archivo DESCRIPTION y se imprime la versión y codificación del paquete.

  • Checking for file ‘googledrive/DESCRIPTION’
  • This is package ‘googledrive’ version ‘2.1.0.9000’
  • Package encoding: UTF-8

A.2 Estructura del paquete

  • Comprobando el directorio de paquetes. El directorio que estás comprobando debe existir; devtools::check() te protege contra este problema.
  • Comprobando si se trata de un paquete fuente. Debe verificar un paquete fuente, no un paquete binario o instalado. Esto nunca debería fallar si usa devtools::check().
  • Buscando archivos ejecutables. No debe tener archivos ejecutables en su paquete: no son portátiles, no son de código abierto y representan un riesgo para la seguridad. Elimine cualquier archivo ejecutable de su paquete. (Si no realiza envíos a CRAN, puede silenciar esta advertencia enumerando cada archivo ejecutable en el campo BinaryFiles en su DESCRIPTION).
  • Buscando archivos y directorios ocultos. En Linux y macOS, los archivos con un nombre que comienza con . están ocultos de forma predeterminada y probablemente los haya incluido en su paquete por error. Elimínelos o, si son importantes, use .Rbuildignore para eliminarlos del paquete. R elimina automáticamente algunos directorios comunes como .git y .svn.
  • Buscando nombres de archivos portátiles. Los paquetes R deben funcionar en Windows, Linux y macOS, por lo que solo puedes usar nombres de archivos que funcionen en todas las plataformas. La forma más sencilla de hacerlo es limitarse a letras, números, guiones bajos y guiones. Evite letras y espacios que no estén en inglés. Solucione esta verificación cambiando el nombre de los archivos enumerados.
  • Comprobación de permisos de archivo suficientes/correctos. Si no puede leer un archivo, no puede verificarlo. Esta verificación detecta el caso poco probable de que tenga archivos en el paquete que no tenga permiso para leer. Solucione este problema arreglando los permisos del archivo.
  • Comprobando si se puede instalar el paquete ‘XYZ’. R CMD check ejecuta R CMD INSTALL para asegurarse de que sea posible instalar su paquete. Si esto falla, debe ejecutar devtools::install() o su equivalente desde los menús de RStudio y depurar cualquier problema antes de continuar.

  • Comprobando el tamaño del paquete instalado. Es fácil incluir accidentalmente archivos grandes que aumentan el tamaño de su paquete. Esta verificación garantiza que todo el paquete tenga menos de 5 MB y que cada subdirectorio tenga menos de 1 MB. Si ve este mensaje, verifique que no haya incluido accidentalmente un archivo grande.

    Si lo envía a CRAN, deberá justificar el tamaño de su paquete. Primero, asegúrese de que el paquete sea lo más pequeño posible: intente recomprimir los datos, Sección 7.1.1; y minimizando viñetas, Capítulo 17. Si todavía es demasiado grande, considere mover los datos a su propio paquete.

  • Comprobando archivos de nivel superior. Solo se permiten archivos y directorios específicos en el nivel superior del paquete (por ejemplo, DESCRIPTION, R/, src/). Para incluir otros archivos, tiene dos opciones:

    • Si no es necesario instalarlos (es decir, solo se usan para tareas de desarrollo), agréguelos a .Rbuildignore con usethis::use_build_ignore().

    • Si es necesario instalarlos: muévalos a inst/. Se moverán nuevamente al directorio de paquetes de nivel superior cuando se instalen. Obtenga más información en Sección 8.2.

  • Comprobando subdirectorios de paquetes.

    • No incluya ningún directorio vacío. Por lo general, estos se eliminan automáticamente con R CMD build, por lo que no deberías ver este error. Si lo hace, simplemente elimine el directorio vacío.

    • Es importante el caso de archivos y directorios. Todos los subdirectorios deben estar en minúsculas, excepto R/. Un archivo de cita, si está presente, debe estar en inst/CITATION. Cambie el nombre según sea necesario.

    • El contenido de inst/ no debe chocar con el contenido de nivel superior del paquete, como data/ o R/. Si es así, cambie el nombre de sus archivos/directorios. Obtenga más información en Sección 8.2.

  • Buscando archivos sobrantes. Elimine los archivos enumerados aquí. Han sido incluidos en tu paquete por accidente.

A.3 DESCRIPTION

  • Comprobando la metainformación de DESCRIPTION.

    • La DESCRIPTION debe ser válida. Es poco probable que vea este error, porque devtools::load_all() ejecuta la misma comprobación cada vez que recarga el paquete.

    • Si utiliza caracteres que no sean ASCII en la descripción, también debe especificar una codificación. Sólo hay tres codificaciones que funcionan en todas las plataformas: latin1, latin2 y UTF-8. Recomendamos encarecidamente UTF-8: Codificación: UTF-8. Obtenga más información en Sección 7.1.3.

    • La License debe hacer referencia a una licencia conocida (puede encontrar una lista completa en https://svn.r-project.org/R/trunk/share/licenses/license.db), o debe usar file LICENSE y ese archivo debe existir. Lo más probable es que los errores aquí sean errores tipográficos. Obtenga más información en Capítulo 12.

    • Debes proporcionar Autores@R o Authorz y Maintainer. Recibirá un error si ha especificado ambos, que puede solucionar eliminando el que no deseaba. Obtenga más información en Sección 9.3.

  • Comprobación de dependencias de paquetes.

    • Todos los paquetes enumerados en Depends, Imports y LinkingTo deben estar instalados y se deben cumplir sus requisitos de versión; de lo contrario, no se podrá verificar su paquete.

    • Los paquetes enumerados en Suggests deben instalarse, a menos que haya configurado la variable de entorno _R_CHECK_FORCE_SUGGESTS_ en un valor falso (por ejemplo, con check(force_suggests = FALSE)). Esto resulta útil si algunos de los paquetes sugeridos no están disponibles en todas las plataformas.

    • Una manera fácil de instalar cualquier dependencia faltante o desactualizada es ejecutar devtools::install_deps(dependencies = TRUE). Consulte también pak::local_install_deps() y pak::local_install_dev_deps().

    • Los paquetes R no pueden tener un ciclo de dependencias: es decir, si el paquete A requiere B, entonces B no puede requerir A (de lo contrario, ¿cuál cargarías primero?). Si ve este error, deberá reconsiderar el diseño de su paquete. Una solución sencilla es mover el paquete en conflicto de Imports o Depends a Suggests.

    • Cualquier paquete utilizado en NAMESPACE debe aparecer en uno de Imports (más comúnmente) o Depends (solo en casos especiales).

    • Cada paquete enumerado en Depends también debe importarse en NAMESPACE o accederse con pkg::foo(). Si no hace esto, su paquete funcionará cuando esté adjunto a la ruta de búsqueda (con library(mypackage)) pero no funcionará cuando solo esté cargado (por ejemplo, mypackage::foo()).

  • Comprobando la viabilidad entrante de CRAN. Estas comprobaciones solo se aplican si realiza el envío a CRAN.

    • Si envía un paquete nuevo, no puede usar el mismo nombre que un paquete existente. Tendrás que pensar en un nuevo nombre.

    • Si envía una actualización, el número de versión debe ser superior a la versión actual de CRAN. Actualice el campo Version en DESCRIPTION.

    • Si el responsable del paquete ha cambiado (incluso si es solo un cambio en la dirección de correo electrónico), el nuevo responsable debe enviarlo a CRAN y el antiguo responsable recibirá un correo electrónico solicitándole que confirme el cambio.

    • Debe utilizar una licencia estándar de código abierto, como se indica en https://svn.r-project.org/R/trunk/share/licenses/license.db. No puede utilizar una licencia personalizada ya que CRAN no tiene los recursos legales para revisar los acuerdos personalizados.

    • El Title y la Description deben estar libres de errores ortográficos. El título del paquete debe estar en mayúsculas y minúsculas. Ni el título ni la descripción deben incluir el nombre de su paquete ni la palabra “paquete”. Vuelva a redactar su título y descripción según sea necesario.

    • Si envía un paquete nuevo, siempre recibirá una “NOTA”. Esto recuerda a los mantenedores de CRAN que deben realizar algunas comprobaciones manuales adicionales.

    • Evite enviar múltiples versiones del mismo paquete en un corto período de tiempo. CRAN prefiere como máximo un envío por mes. Si necesita corregir un error importante, pida disculpas.

A.4 Namespace

  • Comprobando si hay un espacio de nombres. Debe tener un archivo NAMESPACE. Esto lo maneja automáticamente el flujo de trabajo de devtools.
  • Comprobando la información del espacio de nombres del paquete. El NAMESPACE debe ser analizable por parseNamespaceFile() y válido. Si esta verificación falla, es un error en roxygen2.
  • Comprobando si el paquete se puede cargar con las dependencias indicadas. Ejecuta library(pkg) con R_DEFAULT_PACKAGES=NULL, por lo que la ruta de búsqueda está vacía (es decir, estadísticas, gráficos, grDevices, utilidades, conjuntos de datos y métodos no se adjuntan como de costumbre). Un error aquí normalmente indica que le falta una dependencia en uno de esos paquetes.
  • Comprobando si el espacio de nombres se puede cargar con las dependencias indicadas. Ejecuta loadNamespace(pkg) con R_DEFAULT_PACKAGES=NULL. El error suele indicar un problema con el espacio de nombres.

A.5 Código R

  • Comprobación de archivos R en busca de caracteres que no sean ASCII. Para una máxima portabilidad (es decir, para que las personas puedan usar su paquete en Windows), debe evitar el uso de caracteres que no sean ASCII en archivos R. Está bien usarlos en los comentarios, pero los nombres de los objetos no deberían usarlos, y en las cadenas deberías usar escapes Unicode. Consulte las notas específicas de CRAN en Capítulo 6 para obtener más detalles.
  • Comprobación de archivos R en busca de errores de sintaxis. Obviamente su código R debe ser válido. Es poco probable que veas este error si has estado usando devtools::load_all() con regularidad.

  • Comprobación de dependencias en código R. Los errores aquí a menudo indican que olvidó declarar un paquete necesario en la DESCRIPTION. Recuerde que nunca debe usar require() o library() dentro de un paquete; consulte Sección 9.6, Capítulo 10 y Capítulo 11 para obtener más información. más detalles sobre las mejores prácticas.

    Alternativamente, es posible que haya utilizado accidentalmente ::: para acceder a una función exportada desde un paquete. Cambie a :: en su lugar.

  • Comprobación de la coherencia genérica/método de S3. Los métodos S3 deben tener una firma de función compatible con su genérico. Esto significa que el método debe tener los mismos argumentos que su genérico, con una excepción: si el genérico incluye ... el método puede tener argumentos adicionales.

    Una causa común de este error es definir métodos de impresión, porque el genérico print() contiene...:

    # MAL
print.my_class <- function(x) cat("Hi")

# BIEN
print.my_class <- function(x, ...) cat("Hi")

# también ok
print.my_class <- function(x, ..., my_arg = TRUE) cat("Hi")
  • Comprobación de funciones de sustitución. Las funciones de reemplazo (por ejemplo, funciones que se llaman como foo(x) <- y) deben tener valor como último argumento.

  • Comprobando el código R para detectar posibles problemas. Esta es una verificación compuesta para una amplia gama de problemas:

    • Las llamadas a library.dynam() (y library.dynam.unload()) deberían verse como library.dynam("name"), no como library.dynam("name.dll"). Elimine la extensión para corregir este error.

    • Coloque library.dynam() en .onLoad(), no en .onAttach(); coloque packageStartupMessage() en .onAttach(), no en .onLoad(). Coloque library.dynam.unload() en .onUnload(). Si utiliza alguna de estas funciones, asegúrese de que esté en el lugar correcto.

    • No utilices unlockBinding() o assignInNamespace() para modificar objetos que no te pertenecen.

    • Se llama a codetools::checkUsagePackage() para comprobar que sus funciones no utilizan variables que no existen. Esto a veces genera falsos positivos con funciones que usan evaluación no estándar (NSE), como subset() o with(). Generalmente, creemos que debería evitar NSE en las funciones del paquete y, por lo tanto, evitar esta NOTA, pero si no puede, consulte ?globalVariables para saber cómo suprimir esta NOTA.

    • No está permitido utilizar .Internal() en un paquete. Llame a la función contenedora de R o escriba su propia función de C. (Si copia y pega la función C desde la base R, asegúrese de mantener el aviso de derechos de autor, use una licencia compatible con GPL-2 y incluya R-core en el campo Authors@R).

    • De manera similar, no se le permite usar ::: para acceder a funciones no exportadas de otros paquetes. Pídale al responsable del paquete que exporte la función que necesita o escriba su propia versión utilizando funciones exportadas. Alternativamente, si las licencias son compatibles, puede copiar y pegar la función exportada en su propio paquete. Si hace esto, recuerde actualizar Authors@R.

    • No utilice assign() para modificar objetos en el entorno global. Si necesita mantener el estado en todas las llamadas a funciones, cree su propio entorno, como se describe en Sección 7.4.

    • No utilices attach() en tu código. En su lugar, haga referencia explícita a las variables.

    • No utilice data() sin especificar el argumento envir. De lo contrario, los datos se cargarán en el entorno global.

    • No utilice funciones obsoletas o obsoletas. Actualice su código para usar las últimas versiones.

    • Debes usar TRUE y FALSE en tu código (y ejemplos), no T y F.

  • Comprobando si el paquete se puede cargar. R carga su paquete con library(). Un error aquí normalmente indica un problema con .onLoad() o .onAttach().
  • Comprobando si el paquete se puede descargar limpiamente. Se carga con library() y luego detach()es. Si esto falla, verifique .onUnload() y .onDetach().
  • Comprobando si el espacio de nombres se puede descargar limpiamente. Ejecuta loadNamespace("pkg"); descargarNamespace("paquete"). Verifique .onUnload() para ver si hay problemas.
  • Comprobando la carga sin estar en la ruta de búsqueda de la biblioteca. Llama a library(x, lib.loc = ...). El error aquí indica que está haciendo una suposición falsa en .onLoad() o .onAttach().

A.6 Datos

  • Comprobando el contenido del directorio ‘data’.

    • El directorio de datos solo puede contener los tipos de archivos descritos en Sección 7.1.

    • Los archivos de datos pueden contener caracteres que no sean ASCII sólo si la codificación está configurada correctamente. Por lo general, esto no debería ser un problema si está guardando archivos .Rdata. Si ve este error, mire la Codificación() de cada columna en el marco de datos y asegúrese de que ninguna sea “desconocida”. (Por lo general, necesitarás solucionar este problema en algún momento del proceso de importación). Obtenga más información en Sección 7.1.3.

    • Si ha comprimido un archivo de datos con bzip2 o xz, debe declarar al menos Depende: R (>= 2.10) en su DESCRIPTION.

    • Si ha utilizado un algoritmo de compresión subóptimo para sus datos, vuelva a comprimirlos con el algoritmo sugerido.

A.7 Documentación

Si está lidiando específicamente con problemas de documentación, es posible que pueda iterar más rápidamente usando devtools::check_man(), que intenta ejecutar solo el subconjunto relevante de comprobaciones. También llama automáticamente a devtools::document() por usted.

  • Comprobando archivos Rd. Esto verifica que todos los archivos man/*.Rd utilicen la sintaxis Rd correcta. Si esto falla, indica un error en roxygen2.
  • Comprobando metadatos Rd. Los nombres y alias deben ser únicos en todos los archivos de documentación de un paquete. Si encuentra este problema, accidentalmente ha utilizado el mismo @nombre o @alias en varios lugares; asegúrate de que sean únicos.
  • Comprobando anchos de línea Rd. Las líneas de los archivos Rd deben tener menos de 90 caracteres de ancho. Es poco probable que esto ocurra si ajusta su código R, y por lo tanto los comentarios de roxygen, a 80 caracteres. Para URL muy largas, utilice un servicio de acortamiento de enlaces como bit.ly.
  • Comprobando referencias cruzadas de Rd. Los errores aquí suelen representar errores tipográficos.
  • Comprobación de entradas de documentación faltantes. Todos los objetos exportados deben estar documentados. Consulte ?tools::undoc para obtener más detalles.
  • Comprobación de discrepancias en códigos/documentaciones. Esta verificación garantiza que la documentación coincida con el código. Esto nunca debería fallar porque estás usando roxygen2, que automáticamente los mantiene sincronizados y check() normalmente debería volver a document() tu paquete. En cualquier caso, la solución suele ser volver a ejecutar devtools::document().

  • Comprobando las secciones Rd \usage. Todos los argumentos deben estar documentados y todos los @params deben documentar un argumento existente. Es posible que haya olvidado documentar un argumento, que haya olvidado eliminar la documentación de un argumento que eliminó o que haya escrito mal el nombre de un argumento.

    Los métodos S3 y S4 necesitan usar marcas especiales \S3method{} y \S4method{} en el archivo Rd. Roxygen2 generará esto automáticamente.

  • Comprobando el contenido de Rd. Esto busca contenido generado automáticamente por package.skeleton(). Como no estás usando package.skeleton() nunca deberías tener un problema aquí.
  • Comprobación de dependencias no declaradas en ejemplos. Si usa un paquete solo como ejemplo, asegúrese de que aparezca en el campo Suggests. Obtenga más información sobre cómo utilizar diferentes tipos de dependencias en sus ejemplos en Capítulo 11.
  • Comprobando ejemplos. Cada ejemplo de documentación debe ejecutarse sin errores y no debe tardar demasiado. Consulte Sección 16.5 para obtener más detalles.
  • Consultando la versión PDF del manual. Ocasionalmente recibirás un error al crear el manual en PDF. Esto suele deberse a que el pdf está creado con látex y te has olvidado de escapar de algo. Depurar esto es doloroso: lo mejor que puede hacer es buscar los registros de látex y el archivo tex combinado y volver desde allí a los archivos .Rd y luego volver a un comentario de roxygen. Cualquier falla de este tipo es potencialmente un error en roxygen2, así que abra un problema.

A.8 Demos

  • Comprobando información del índice. Si ha escrito demostraciones, cada demostración debe aparecer en demo/00Index. El archivo debería verse así:

    demo-name-without-extension  Demo description
another-demo-name            Another description

A.9 Código compilado

  • Comprobando llamadas a funciones externas. .Call(), .C(), .Fortran(), .External() siempre deben llamarse con un objeto NativeSymbolInfo (como se creó con @useDynLib) o usar el Argumento .paquete. Consulte ?tools::checkFF para obtener más detalles.
  • Comprobando finales de línea en C/C++/fuentes/encabezados de Fortran. Utilice siempre LF como final de línea.
  • Comprobando finales de línea en Makefiles. Como anteriormente.
  • Comprobando el uso portátil de $(BLAS_LIBS) y $(LAPACK_LIBS). Los errores aquí indican un problema con el uso de BLAS y LAPACK.
  • Comprobando el código compilado. Comprueba que no estás utilizando ninguna función de C que no deberías.

A.10 Pruebas

  • Comprobación de dependencias no declaradas en las pruebas. Cada paquete utilizado por las pruebas debe incluirse en las dependencias.

  • Comprobación de pruebas. Se ejecuta cada archivo en tests/. Si ha seguido las instrucciones en Capítulo 13, tendrá al menos un archivo: testthat.R. El resultado de R CMD check no suele ser tan útil, por lo que es posible que deba consultar el archivo de registro package.Rcheck/tests/testthat.Rout. Corrija cualquier prueba fallida iterando con devtools::test().

    Ocasionalmente, puede tener un problema donde las pruebas pasan cuando se ejecutan interactivamente con devtools::test(), pero fallan cuando se ejecutan en R CMD check. Esto generalmente indica que ha hecho una suposición errónea sobre el entorno de prueba y, a menudo, es difícil descifrarla.

A.11 Viñetas

Este es un tema bastante complicado que también recibe una cobertura sustancial en la parte principal del libro; consulte Sección 17.5.

  • Comprobando el directorio ‘build’. build/ se utiliza para realizar un seguimiento de las compilaciones de viñetas. Es difícil imaginar cómo esta verificación podría fallar a menos que accidentalmente hayas ignorado .Rbuild el directorio build/.
  • Comprobando archivos instalados desde ‘inst/doc’. No coloque archivos en inst/doc; mantenga sus viñetas y los archivos que necesitan en vignettes/.
  • Comprobación de archivos en ‘viñetas’. Los problemas aquí suelen ser sencillos: ha incluido archivos que ya están incluidos en R (como jss.cls, jss.bst o Sweave.sty), o le sobran archivos de compilación de látex. Elimina estos archivos.
  • Comprobación del tamaño de los archivos PDF en ‘inst/doc’. Si está creando viñetas en PDF, puede hacerlas lo más pequeñas posible ejecutando tools::compactPDF().
  • Comprobación de dependencias no declaradas en viñetas. Al igual que con las pruebas, cada paquete que utilice en una viñeta debe aparecer en la DESCRIPTION. Si un paquete se usa solo para una viñeta y no en ningún otro lugar, asegúrese de que aparezca en Suggests. Si realmente desea utilizar un paquete y no desea incluirlo en DESCRIPTION, escriba un artículo en lugar de una viñeta.
  • Comprobación de viñetas de paquetes en ‘inst/doc’. Esto verifica que cada viñeta fuente (es decir, .Rmd) tenga un equivalente integrado (es decir, .html) en inst/doc. Esto no debería fallar si ha utilizado el proceso estándar descrito en Capítulo 17. Si hay algún problema, comience revisando su .Rbuildignore.
  • Comprobación del código R en ejecución a partir de viñetas. Se ejecuta el código R de cada viñeta. Si desea ejecutar errores deliberadamente (para mostrarle al usuario cómo se ve la falla), asegúrese de que el fragmento tenga error = TRUE, purl = FALSE.
  • Comprobando la reconstrucción de los resultados de las viñetas. Cada viñeta se vuelve a tejer para garantizar que la salida corresponda con la entrada. Nuevamente, esto no debería fallar en circunstancias normales.

A.12 NOTAS que son informativas

Nuestro consejo general es eliminar todos los ERRORES, ADVERTENCIAS e incluso NOTAS que vea en “R CMD check”. Pero hay algunas excepciones, es decir, hay un par de NOTAS que no necesita corregir (y, de hecho, probablemente no pueda corregir).

A.12.1 Envío inicial de CRAN

Cuando un paquete llega por primera vez a CRAN, siempre habrá una NOTA que alerta a los mantenedores de CRAN que se trata de un nuevo envío y que necesitarán realizar algunas comprobaciones adicionales. No puedes eliminar esta NOTA.

* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Jane Doe <jane@example.com>'

New submission

A.12.2 Caracteres no ASCII en datos

Si los datos de su paquete contienen caracteres que no son ASCII, recibirá una NOTA como esta, pero eso no significa necesariamente que deba hacer algo al respecto.

Check: data for non-ASCII characters
Result: NOTE
     Note: found 25 marked UTF-8 strings

Siempre que conozca los caracteres que no son ASCII y la NOTA mencione su codificación prevista y declarada (preferiblemente UTF-8), todo estará bien.

A.12.3 Rd referencias cruzadas

Si sus comentarios de roxygen contienen una referencia cruzada a un paquete que no es una dependencia directa y formal, es posible que vea una NOTA como esta:

Check: Rd cross-references
Result: NOTE
    Undeclared package ‘jsonlite’ in Rd xrefs

Esto podría suceder si desea documentar algo relacionado con una dependencia indirecta estricta: hay una razón legítima para vincular un tema en el otro paquete y básicamente se garantiza su instalación. Por lo tanto, en la práctica, a menudo se obtienen más beneficios que daños de la referencia cruzada.

Según nuestra experiencia, esta NOTA solo se ve en ciertos sabores de cheques CRAN y no en otros. Hasta ahora, los mantenedores de CRAN nunca nos han indicado que abordemos esta NOTA.