[ERR_PNPM_UNEXPECTED_STORE] Ubicación de almacén inesperada al agregar paquetes npm a Task Runners

Hola a todos,

Recientemente enfrenté este problema y logré resolverlo. Quería publicar mis hallazgos aquí en caso de que este no sea el comportamiento deseado, o en caso de que le ayude a alguien más.

El Problema

Después de la última versión «beta» [2.29.5] de los ejecutores de tareas, comencé a recibir este error al intentar compilar una imagen de ejecutor personalizada:

#13 [stage-1 7/8] RUN cd /opt/runners/task-runner-javascript && pnpm add moment uuid
#13 0.829 ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.10.0.tgz
#13 2.407 [ERR_PNPM_UNEXPECTED_STORE] Unexpected store location
#13 2.407 
#13 2.407 The dependencies at "/opt/runners/task-runner-javascript/node_modules" are currently linked from the store at "/root/.local/share/pnpm/store/v10".
#13 2.407 
#13 2.407 pnpm now wants to use the store at "/root/.local/share/pnpm/store/v11" to link dependencies.
#13 2.407 
#13 2.407 If you want to use the new store location, reinstall your dependencies with "pnpm install".
#13 2.407 
#13 2.407 You may change the global store location by running "pnpm config set store-dir <dir> --global".
#13 2.407 (This error may happen if the node_modules was installed with a different major version of pnpm)
#13 ERROR: process "/bin/sh -c cd /opt/runners/task-runner-javascript && pnpm add moment uuid" did not complete successfully: exit code: 1

Los Síntomas

  1. El Error de Almacén: Al ejecutar un comando estándar pnpm add en mi Dockerfile personalizado, obtuve [ERR_PNPM_UNEXPECTED_STORE]. Los node_modules de la imagen base estaban vinculados a un almacén v10, pero mi paso de compilación intentaba usar un almacén v11.
  2. El Error de npx: Intenté forzar pnpm v10 usando npx -y pnpm@10 add ..., pero la imagen base está construida sobre python:alpine y solo copia el binario node y corepack. No incluye npm o npx, lo que resulta en /bin/sh: npx: not found.

La Causa Raíz

Mirando el código fuente de n8n, recientemente actualizaron los Dockerfiles del ejecutor para fijar explícitamente PNPM_VERSION=10.32.1 durante su proceso de compilación (Commit 25d0d12).

Hicieron esto porque pnpm deploy elimina el campo packageManager, por lo que un corepack enable pnpm simple se resuelve en pnpm 11.x. pnpm 11 establece por defecto minimumReleaseAge en 24 horas, lo que rechaza las dependencias publicadas hace menos de un día.

Sin embargo, si simplemente ejecutas un pnpm add simple en tu Dockerfile personalizado, corepack ignora esta versión fijada y descarga automáticamente la versión más nueva (v11). pnpm 11 utiliza un formato de almacén diferente y se niega a interactuar con el almacén v10 que dejó atrás la imagen base.

La Solución

Para solucionar esto, debes usar corepack para activar explícitamente pnpm v10 antes de ejecutar tu comando pnpm add.

En lugar de hacer esto:

RUN cd /opt/runners/task-runner-javascript && \
    pnpm add moment uuid

Cambia tu paso de Dockerfile a esto:

# Activate pnpm 10.32.1 to match the base image's v10 store (npx is not available in this image)
RUN corepack prepare pnpm@10.32.1 --activate && \
    cd /opt/runners/task-runner-javascript && \
    pnpm add \
    moment \
    uuid

¡Espero que esto le ahorre a alguien más algunas horas de depuración! También agradecería si alguien pudiera confirmar si fijar la versión a v10 es el comportamiento esperado en adelante.

¡Excelente compartición, @mohamed3nan!!

Gracias por esto, he creado CAT-3666 como el ticket de desarrollo interno para resolver esto.

Gracias por encontrar esa solución @mohamed3nan. ¡Me ahorró mucha investigación!. Es un poco frágil si cambian la versión, así que la actualicé para leer explícitamente la versión actual de la siguiente manera:

RUN PNPM_VER=$(sed -n 's/.*"packageManager": "pnpm@\([^"]*\)".*/\1/p' /opt/runners/task-runner-javascript/node_modules/.modules.yaml) && \
    corepack prepare pnpm@${PNPM_VER} --activate && \
    cd /opt/runners/task-runner-javascript && \
    pnpm add \
        <list-of-packages>

Espero que haya una solución adecuada antes de que la versión cambie, pero es mejor estar seguro.