Para comprobar qué entregará realmente un paquete compartido de npm workspace, ejecute sus pruebas desde el monorrepo, empaquete el workspace y luego instale ese archivo tarball en un directorio consumidor temporal independiente en su Mac. Esto detecta problemas ocultos por el enlace simbólico (symlink) local del workspace de npm, como archivos compilados faltantes o un punto de entrada del paquete incorrecto. No publica nada en ningún registro.

1. Ejecutar las pruebas propias del paquete desde la raíz del workspace

Abra la Terminal y navegue hasta la raíz del monorrepo: el directorio que contiene el package.json raíz. Confirme que el paquete aparezca en la configuración workspaces de la raíz y que tenga su propio package.json. npm instala los workspaces configurados como enlaces en el node_modules de la raíz, por lo que una ejecución de pruebas allí puede resolver el código fuente en vivo del workspace. La opción de workspace le permite apuntar a un paquete mediante su nombre declarado o su directorio. npm Workspaces

Ejecute el script de prueba del paquete por su nombre de workspace, sustituyendo el nombre de su package.json:

npm run test --workspace=@acme/math

Si el paquete utiliza un nombre de script diferente, use ese nombre. Si no tiene un script de prueba, este comando no puede probar su comportamiento; ejecute las comprobaciones que el proyecto realmente defina, como sus scripts de compilación (build) o linting. Evite depender únicamente de un comando de prueba a nivel de raíz: los comandos de npm como test operan en la raíz a menos que seleccione un workspace. npm Workspaces

2. Revisar y crear el tarball del paquete

Una prueba local en el workspace no demuestra que los archivos que necesitan los consumidores estén incluidos en el paquete. Primero obtenga una vista previa del contenido del paquete del workspace seleccionado desde la raíz del monorrepo:

npm pack --workspace=@acme/math --dry-run

Revise la lista de archivos para verificar el punto de entrada del paquete, los resultados compilados, las declaraciones de tipos y cualquier otro archivo que el paquete prometa. Las configuraciones de files, .npmignore y .gitignore de npm afectan el contenido; package.json, así como los archivos README y de licencia, se encuentran entre los que npm incluye de forma predeterminada. Compruebe que main o exports apunten a archivos que estarán en el archivo comprimido. npm pack, package.json files and entry points

Cuando la lista parezca correcta, cree un archivo tarball real en un directorio temporal. Los siguientes comandos utilizan el entrecomillado compatible con zsh predeterminado de macOS y mantienen el artefacto fuera de su repositorio:

scratch="$(mktemp -d "${TMPDIR:-/tmp}/workspace-package-check.XXXXXX")"
npm pack --workspace=@acme/math --pack-destination="$scratch"

--dry-run solo informa lo que npm empaquetaría; no crea el archivo comprimido. El segundo comando sí crea uno, pero no lo sube. La documentación de npm describe npm pack como una herramienta para crear un tarball y reconoce el selector de workspace. npm pack

3. Instalar el archivo en una carpeta de consumo limpia

Busque la ruta del tarball, cree un directorio de consumo independiente e instale el archivo comprimido allí. Este ejemplo asume que solo se empaquetó un tarball en el directorio temporal:

tarball="$(find "$scratch" -maxdepth 1 -name '*.tgz' -print -quit)"
consumer="$scratch/consumer"
mkdir -p "$consumer"
cd "$consumer"
npm init -y
npm install "$tarball"

Instalar un .tgz pone a prueba el artefacto empaquetado. Instalar una carpeta de workspace o utilizar la dependencia enlazada del monorrepo puede comportarse de manera diferente. npm install

Ahora pruebe el paquete a través de su punto de entrada público. Utilice el nombre real del paquete y una pequeña verificación de consumo adaptada a su API; por ejemplo, use require o import con él, y luego llame a una función exportada representativa. Ejecute esa comprobación desde el directorio del consumidor, donde el paquete se resuelve a partir del node_modules recién instalado. Si el proyecto publica resultados compilados, verifique que la compilación se haya ejecutado antes de empaquetar; de lo contrario, podrían faltar archivos en el archivo comprimido aunque las pruebas en tiempo de desarrollo hayan pasado.

4. Diagnosticar fallos antes de publicar

Si la instalación falla, compruebe que el archivo tenga un package.json con name y version, luego inspeccione su lista de archivos y confirme que los puntos de entrada configurados existan en el tarball. Si la importación falla, compare el formato de módulo del consumidor con las configuraciones type, main y exports del paquete. Un paquete puede pasar las pruebas del workspace y aun así fallar aquí, ya que esas pruebas pueden cargar archivos fuente directamente o resolver dependencias no declaradas desde el monorrepo.

Si una dependencia es otro workspace no publicado, pruebe también la disposición de publicación prevista. Un consumidor que instale un tarball no recibirá automáticamente el código fuente del workspace hermano a través del enlace del monorrepo. Asegúrese de que los paquetes hermanos estén publicados/disponibles en versiones compatibles, o utilice una configuración empaquetada (bundled) o instalable deliberada. Este procedimiento verifica un paquete empaquetado local en el entorno actual de Mac/Node; no puede establecer el comportamiento en todas las versiones de Node, sistemas operativos o configuraciones de registros.

El punto de parada conveniente es una prueba de workspace superada, una lista de archivos de paquete verosímil y una verificación de consumidor que instale y ponga a prueba el tarball desde fuera del monorrepo. Conserve el directorio temporal si necesita inspeccionarlo, o elimínelo con rm -rf "$scratch" tras confirmar que la variable aún hace referencia a la ruta temporal generada.

Fuentes