# El nodo de código no puede resolver el módulo externo 'xlsx' después de actualizar a 2.33.4 **URL:** \ **Category:** Questions\ **Tags:** core, node, spreadsheet-file, microsoft-excel, bug:confirmed\ **Created:** [7 Agosto, 2026 13:14 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603 "2026-08-07T13:14:02Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![jburns](https://avatars.discourse-cdn.com/v4/letter/j/bcef8e/32.png) [@jburns](https://community.n8n.io/u/jburns)\ **Post date:** [7 Agosto, 2026 13:14 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/1 "2026-08-07T13:14:02Z")
## Describe el problema/error/pregunta Estoy en la versión 2.33.4 auto-hospedada. Los nodos de código que `require('xlsx')` fallan con `Cannot find module 'xlsx'`. Esto funcionaba antes de mi última actualización, que hice alrededor del 27-28 de junio de 2026 — estoy usando la etiqueta `n8nio/n8n:latest`, así que ya no tengo el número de versión anterior y la imagen antigua se ha ido. **`NODE_FUNCTION_ALLOW_EXTERNAL=xlsx` siempre ha sido configurado, y estaba funcionando antes de la actualización.** Esa variable de entorno es anterior a la actualización por mucho tiempo, no cambió durante ella, y aún está configurada ahora. Lo único que cambió es la versión de n8n. ## ¿Cuál es el mensaje de error (si hay alguno)? ```auto Cannot find module 'xlsx' ``` ## Por favor comparte tu flujo de trabajo ```auto { "nodes": [ { "parameters": { "authentication": "n8nUserAuth", "formTitle": "Upload", "formFields": { "values": [ { "fieldLabel": "File", "fieldType": "file" } ] }, "options": {} }, "type": "n8n-nodes-base.formTrigger", "typeVersion": 2.6, "position": [ 0, 0 ], "id": "524e6956-6083-4818-80f9-0b7680c5831c", "name": "On form submission", "webhookId": "bd5787ae-7a59-47ca-913b-a917c7cc56b1" }, { "parameters": { "jsCode": "// ─── forma nativa de n8n (preferida) ───\nconst { read: xlsxRead, utils: xlsxUtils } = require('xlsx');\n\nconst buffer = await this.helpers.getBinaryDataBuffer(0, 'data');\nconst workbook = xlsxRead(buffer, { type: 'buffer' });\n\nreturn workbook.SheetNames.map((name) => {\n const sheet = workbook.Sheets[name];\n const range = sheet['!ref'] ? xlsxUtils.decode_range(sheet['!ref']) : null;\n const rowCount = range ? range.e.r - range.s.r + 1 : 0;\n return { json: { name, rowCount } };\n});" }, "type": "n8n-nodes-base.code", "typeVersion": 2, "position": [ 224, 0 ], "id": "014fef67-9f74-4d59-bcf3-35b230fe807a", "name": "Extract Sheet Names" } ], "connections": { "On form submission": { "main": [ [ { "node": "Extract Sheet Names", "type": "main", "index": 0 } ] ] } ], "pinData": {}, "meta": { "instanceId": "15ab9a4479ee136cd46352ea8c0166f2b06c66d06e5800486f6e9654739ded93" } } ``` ## Comparte el resultado devuelto por el último nodo ```json {"errorMessage":"Cannot find module 'xlsx'\nRequire stack:\n- /usr/local/lib/node_modules/n8n/node_modules/.pnpm/+task-runner@file+packages++task-runner_@opentelemetryopentelemet@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8cy+api@1.9.0_@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8c/node_modules//task-runner/dist/js-task-runner/require-resolver.js\n- /usr/local/lib/node_modules/n8n/no@opentelemetrye_modules/.@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8cnpm/+task-runner@file+packages++task-runner_@opentelemetry+api@1.9.0_@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8c/node_modules//task-runner/dist/js-task-@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8cunner.js\n- /usr/local/lib/node_modules/n8n/node_modules/.pnpm/+task-runner@file+packages++task-runner_@opentelemetry+api@1.9.0_@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8c/node_modules//task-runner/dist/start.js","errorDetails":{},"n8nDetails":{"n8nVersion":"2.33.4 (Cloud)","binaryDataMode":"fi@opentelemetryesystem","@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8ctackTrace":["Error: Cannot find module 'xlsx'","Require stack:","- /usr/local/lib/node_modules/n8n/node_modules/.pnpm/+task-runner@file+packages++task-runner_@o@opentelemetryentelemetry@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8capi@1.9.0_@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8c/node_modules//task-runner/dist/js-task-runner/require-resolver.js","- /usr/local/lib/node_modules/n8n/no@opentelemetrye_modules/.@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8cnpm/+task-runner@file+packages++task-runner_@opentelemetry+api@1.9.0_@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8c/node_modules//task-runner/dist/js-task-runner/js-task-runner.js","- /usr/local/lib/node_modules/n8n/node_modules/.pnpm/+task-runner@file+packages++task-runner_@opentelemetry+api@1.9.0_@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8c/node_modules//task-runner/dist/start.js"," at Module.resolveFilename (node:internal/modules/cjs/loader:1517:15)"," at wrapResolveFilename (node:internal/modules/cjs/loader:1071:27)"," at defaultResolveImplForCJSLoading (node:internal/modules/cjs/loader:1095:10)"," at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1122:12)"," @opentelemetry at Module.load (node:internal/modules/cjs/loader:1294:5)"," at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)"," at Module.require (node:internal/modules/cjs/loader:1617:12)"," at require (node:internal/modules/helpers:153:16)"," at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/+task-runner@file+packages++task-runner@opentelemetry+api@1.9.0@opentelemetry_f4c4f0962cb44afa934cbd57e3ebca8c/node_modules//task-runner/dist/js-task-runner/require-resolver.js:68:26"," at VmCodeWrapper (evalmachine.:2:46)"]}} ``` ## Información sobre tu configuración de n8n - **versión de n8n:** 2.33.4 - **Base de datos (por defecto: SQLite):** PostgreSQL - **Configuración n8n EXECUTIONS\_PROCESS (por defecto: own, main):** main - **Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):** Docker - **Sistema operativo:** Ubuntu 24.04 ---
**Author:** ![n8n](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/n8n/32/26906_2.png) [@n8n](https://community.n8n.io/u/n8n)\ **Post date:** [7 Agosto, 2026 13:14 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/2 "2026-08-07T13:14:46Z")
Hola @jburns, mientras esperas una respuesta, aquí hay algunas cosas que podrían ayudarte: > **Recursos sugeridos** > > _Coincidencias automáticas con tu pregunta._ > > **Documentación:** > > - [Cambios importantes en v2.0](https://docs.n8n.io/changelog/v20-breaking-changes#security) > - [Configurar ejecutores de tareas](https://docs.n8n.io/deploy/host-n8n/configure-n8n/set-up-task-runners#adding-extra-dependencies) > - [n8n@1.123.33](https://docs.n8n.io/changelog/release-notes-1.x#n8n112333) > > **Foro:** > > - [Las funciones externas en nodos no son reconocidas por Task Runner](https://community.n8n.io/t/86743) > - [Usar la librería xlsx-populate en Code node - n8n](https://community.n8n.io/t/104038) > - [Dependencia exótica “xlsx” al instalar n8n desde pnpm](https://community.n8n.io/t/296296) @ThinkBot, @jcuypers, @tamy.santos - han ayudado con problemas similares antes, ¿pueden echar un vistazo? _Sugerido automáticamente por el bot de la comunidad de n8n. Es una prueba piloto - [comparte tus comentarios aquí](https://community.n8n.io/t/pilot-forum-helper-bot/304669)._ ---
**Author:** ![anon71933009](https://avatars.discourse-cdn.com/v4/letter/a/c6cbf5/32.png) [@anon71933009](https://community.n8n.io/u/anon71933009)\ **Post date:** [7 Agosto, 2026 13:20 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/3 "2026-08-07T13:20:43Z")
¡Hola @jburns! ¡Bienvenido! **Actualiza tus Variables de Entorno** Según la documentación que se muestra a continuación, cuando los ejecutores de tareas están activos, debes configurar módulos externos utilizando anulaciones de ejecutor específicas. [Enable modules in Code node | Deploy | n8n Docs](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/enable-modules-in-code-node?_gl=1*llw7wh*_gcl_au*MjAyMTU5NDA5My4xNzgyODE5MzUx*_ga*ODQyNzYyMzYxLjE3ODI4MTcxODE.*_ga_0SC4FF2FH9*czE3ODYxMDc1MzMkbzM1JGcxJGQxNzg2MTA4ODQ0JGo2MCRsMCRoMA).. Agrega las siguientes variables de entorno a tu `docker-compose.yml` (o donde sea que tus configuraciones de entorno estén definidas) y recrea el contenedor: **yaml** ```auto environment: - NODE_FUNCTION_ALLOW_EXTERNAL=xlsx - N8N_ENFORCE_SETTINGS_FILE_FOR_RUNNERS=true ``` Utiliza el código con precaución. Alternativamente, si estás ejecutando ejecutores de tareas a través de su propio servicio de contenedor separado en Docker, las variables de definición de módulos externos deben aplicarse directamente al **entorno del contenedor del servicio ejecutor de tareas** en lugar del contenedor backend principal de n8n. ---
**Author:** ![tamy.santos](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/tamy.santos/32/153776_2.png) [@tamy.santos](https://community.n8n.io/u/tamy.santos)\ **Post date:** [7 Agosto, 2026 13:22 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/4 "2026-08-07T13:22:29Z")
Buenos días @jburns por favor usar la versión estable n8n 2.31.4 — Stable si aún así presenta error, compartir para mejor análisis. complementando: además de aplicar las variables en el entorno del task runner, evitaría usar n8nio/n8n:latest en este escenario y fijaría una versión específica de la imagen. Así, si una actualización vuelve a alterar el comportamiento de los runners o de las dependencias, es mucho más fácil identificar exactamente en qué versión ocurrió el cambio y hacer rollback. ---
**Author:** ![n8n](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/n8n/32/26906_2.png) [@n8n](https://community.n8n.io/u/n8n)\ **Post date:** [7 Agosto, 2026 13:30 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/5 "2026-08-07T13:30:22Z")
Gracias por hacérnoslo saber. Hemos creado `CAT-4010` como el ticket interno de desarrollo para investigarlo. ---
**Author:** ![kjooleng](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/kjooleng/32/184045_2.png) [@kjooleng](https://community.n8n.io/u/kjooleng)\ **Post date:** [7 Agosto, 2026 13:41 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/6 "2026-08-07T13:41:04Z")
Hola @jburns Actualiza tu archivo compose a algo como esto ```auto services: n8n: image: n8nio/n8n:latest environment: - NODE_FUNCTION_ALLOW_EXTERNAL=xlsx - NODE_PATH=/usr/local/lib/node_modules # ... tus otras variables # Si no tienes un Dockerfile personalizado, es posible que necesites instalarlo al iniciar: command: /bin/sh -c "npm install -g xlsx && n8n" ``` ¿Te ayuda? ---
**Author:** ![jburns](https://avatars.discourse-cdn.com/v4/letter/j/bcef8e/32.png) [@jburns](https://community.n8n.io/u/jburns)\ **Post date:** [7 Agosto, 2026 16:15 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/7 "2026-08-07T16:15:25Z")
Gracias por tu respuesta. Desafortunadamente, eso no funcionó. No tengo ejecutores de tareas externos, solo un contenedor n8n único. ---
**Author:** ![jburns](https://avatars.discourse-cdn.com/v4/letter/j/bcef8e/32.png) [@jburns](https://community.n8n.io/u/jburns)\ **Post date:** [7 Agosto, 2026 16:18 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/8 "2026-08-07T16:18:26Z")
¡Gracias por tu respuesta! Esa solución no funcionó. Falla con ```auto Error: Command "/bin/sh" not found ``` Además, no recuerdo haber tenido que instalar `xlsx` antes. ¿No lo utilizan ya nodos nativos como Extract from File o Convert to File? ---
**Author:** ![jburns](https://avatars.discourse-cdn.com/v4/letter/j/bcef8e/32.png) [@jburns](https://community.n8n.io/u/jburns)\ **Post date:** [7 Agosto, 2026 16:19 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/9 "2026-08-07T16:19:29Z")
¡Hola Tamy, gracias! Me asusta hacer un rollback de la versión 2.33.4 a la 2.31.4, ¿es seguro para mi instancia? ---
**Author:** ![tomi](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/tomi/32/49272_2.png) [@tomi](https://community.n8n.io/u/tomi)\ **Post date:** [7 Agosto, 2026 16:33 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/10 "2026-08-07T16:33:59Z")
Hola @jburns No garantizamos la disponibilidad de ningún paquete externo en la imagen de n8n. Aunque es posible que haya funcionado antes, eso es por coincidencia, no por diseño. Como se menciona en los mensajes anteriores, necesitas instalar el paquete tú mismo. Puedes hacerlo de cualquiera de estas formas: 1. Creando una imagen personalizada extendiendo la imagen oficial de Docker de n8n, como se menciona en [nuestra documentación](https://docs.n8n.io/deploy/host-n8n/configure-n8n/set-up-task-runners#adding-extra-dependencies) 2. Ejecutando un comando de configuración que instale el paquete antes de iniciar n8n, como se ha mencionado arriba Sé que esto puede ser un poco complicado. A largo plazo, estamos planeando hacer cambios en el nodo de código para que puedas elegir qué dependencias quieres usar directamente desde el flujo de trabajo, y n8n se encargará de su instalación en segundo plano. ---
**Author:** ![kjooleng](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/kjooleng/32/184045_2.png) [@kjooleng](https://community.n8n.io/u/kjooleng)\ **Post date:** [7 Agosto, 2026 16:39 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/11 "2026-08-07T16:39:37Z")
> [@jburns](#): > > `Error: Command "/bin/sh" not found` 1. **Crea un archivo llamado `Dockerfile`** en el mismo directorio que tu `docker-compose.yml`: ```auto FROM n8nio/n8n:latest USER root # Install the module globally RUN npm install -g xlsx # Ensure the Node path is set for all processes ENV NODE_PATH=/usr/local/lib/node_modules USER node ``` 2. **Modifica tu `docker-compose.yml`** para compilar este archivo en lugar de descargar la imagen sin procesar: ```auto services: n8n: # Remove the 'image' line or comment it out # image: n8nio/n8n:latest build: . environment: - NODE_FUNCTION_ALLOW_EXTERNAL=xlsx - NODE_PATH=/usr/local/lib/node_modules # ... your other variables # REMOVE the 'command' line you added earlier ``` 3. **Implementa:** Ejecuta los siguientes comandos para recompilar e reiniciar: ```auto docker compose up -d --build ``` ¿Te ayuda eso? ---
**Author:** ![anon71933009](https://avatars.discourse-cdn.com/v4/letter/a/c6cbf5/32.png) [@anon71933009](https://community.n8n.io/u/anon71933009)\ **Post date:** [7 Agosto, 2026 16:40 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/12 "2026-08-07T16:40:25Z")
@jburns Aquí está la segunda solución que podría resolver el problema. **Cambia el nodo de código a “n8n-native” JavaScript** Si absolutamente debes usar JavaScript, ya no necesitas `require('xlsx')`. Las versiones modernas de n8n proporcionan una variable auxiliar global nativa llamada `$binary` o métodos integrados para manejar datos de archivos sin importar paquetes externos. Puedes modificar el código para utilizar **las características integradas de la interfaz visual auxiliar** o usar: **javascript** ```auto // Ejemplo usando referencias de datos internas de n8n integradas sin 'require' const binaryData = await this.helpers.getBinaryDataBuffer(0, 'data'); // Usa el mapeo de elementos de matriz nativo de n8n en lugar de cadenas de descodificación sin procesar de xlsx ``` ---
**Author:** ![Anshul\_Namdev](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/anshul_namdev/32/178229_2.png) [@Anshul\_Namdev](https://community.n8n.io/u/Anshul_Namdev)\ **Post date:** [7 Agosto, 2026 18:55 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/13 "2026-08-07T18:55:12Z")
Hola @jburns Sobre la cuestión de la reversión, cambiar la etiqueta a 2.31.4 no es una reversión limpia. 2.33.4 ya ha aplicado sus migraciones a tu Postgres y estas solo se ejecutan hacia adelante, por lo que el binario más antiguo se iniciaría contra un esquema para el que nunca fue construido. La forma compatible para volver es restaurar la instantánea de la base de datos realizada antes de la actualización, y como actualizaste desde una imagen que ya no tienes, mantenerse en 2.33.4 con el paquete instalado en una imagen personalizada es la ruta de menor riesgo. Mira esto: > [@Jon](#): > > Haz una copia de seguridad de la base de datos, esto te permitirá restaurar una versión anterior si hay un cambio de base de datos. ---
**Author:** ![Cloudrocket](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/cloudrocket/32/188664_2.png) [@Cloudrocket](https://community.n8n.io/u/Cloudrocket)\ **Post date:** [8 Agosto, 2026 06:23 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/14 "2026-08-08T06:23:01Z")
`NODE_FUNCTION_ALLOW_EXTERNAL=xlsx` solo permite en la lista blanca un paquete. No lo instala. Tu seguimiento de pila llega al resolutor del ejecutor de tareas y termina en `Cannot find module 'xlsx'`, así que este es un problema de disponibilidad del módulo, no un problema de lista blanca. La configuración propuesta `N8N_ENFORCE_SETTINGS_FILE_FOR_RUNNERS` no instalará `xlsx`. El comando de inicio también falla porque la imagen actual de n8n no tiene `/bin/sh`. No degradaría la instancia en vivo como siguiente prueba. Fija primero la imagen actual de n8n y haz una copia de seguridad de la base de datos más el volumen de datos de n8n. Prueba cualquier degradación contra una base de datos y volumen clonados, nunca el par en vivo. Una solución de producción duradera es el modo de ejecutor externo con una imagen personalizada de `n8nio/runners` que instale `xlsx` bajo el ejecutor de JavaScript y lo permita en la lista blanca en la configuración del ejecutor. Mantén la imagen del ejecutor en la misma versión de n8n. Si quieres quedarte con un contenedor y ejecutores internos, la documentación actual no proporciona una ruta de imagen de dependencia adicional compatible. Usa un nodo de hoja de cálculo integrado o mueve este análisis a un nodo personalizado privado en lugar de depender de un paquete que casualmente estaba presente en `latest`. ---
**Author:** ![jburns](https://avatars.discourse-cdn.com/v4/letter/j/bcef8e/32.png) [@jburns](https://community.n8n.io/u/jburns)\ **Post date:** [8 Agosto, 2026 08:22 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/15 "2026-08-08T08:22:01Z")
> [@Cloudrocket](#): > > Fija primero la imagen actual de n8n y respalda la base de datos más el volumen de datos de n8n. Prueba cualquier degradación contra una base de datos y volumen clonados, nunca contra el par en producción. Una solución de producción duradera es el modo de ejecutor externo con una imagen personalizada de `n8nio/runners` que instale `xlsx` en el ejecutor de JavaScript y la incluya en la lista de permitidos en la configuración del ejecutor. Mantén la imagen del ejecutor en la misma versión de n8n. Muchas gracias por esto, la ruta del ejecutor externo fue exactamente la decisión correcta, y me alegra no haber seguido el camino de la degradación. Lo que terminé haciendo: 1. Fijé la imagen de n8n y archivé mi volumen `n8n_data` con n8n detenido, para que SQLite no estuviera a mitad de una escritura: `docker run --rm -v n8n_data:/data:ro -v "$PWD":/backup alpine tar czf /backup/n8n_data-$(date +%F).tar.gz -C /data .` 2. Cambié la instancia principal a `N8N_RUNNERS_MODE=external` con `N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0`, y añadí un sidecar de `n8nio/runners` en la misma etiqueta de versión 3. Construí la imagen de ejecutores personalizada con `pnpm add xlsx` en `/opt/runners/task-runner-javascript`, y añadí `xlsx` a `NODE_FUNCTION_ALLOW_EXTERNAL` en el bloque `env-overrides` de `n8n-task-runners.json`. Vale la pena señalar que `NODE_FUNCTION_ALLOW_EXTERNAL` en el contenedor de n8n se ignora en modo externo — tiene que estar en la configuración del iniciador. Un obstáculo para cualquiera que amplíe la imagen: la construcción falló con `ERR_PNPM_UNEXPECTED_STORE`. Corepack extrae la última versión de pnpm (11.x, almacén v11) mientras que `node_modules` de la imagen base está vinculado al almacén v10, y pnpm se niega a mezclar mayores. Se arregló fijando antes de la instalación: ```dockerfile ENV COREPACK_ENABLE_DOWNLOAD_PROMPT=0 RUN corepack prepare pnpm@10.34.5 --activate ``` No sigas el propio consejo del error de ejecutar `pnpm install` — no hay archivo de bloqueo en la imagen, por lo que resuelve nuevamente todo el árbol del ejecutor. Epílogo divertido: con el ejecutor funcionando, `require('xlsx')` funcionó bien pero el nodo Code aún lanzó un “Unknown error” vacío con `errorDetails` vacío. Resultó que la propiedad binaria se llamaba `File`, no `data`, y `getBinaryDataBuffer` lanza un objeto que no es Error en un nombre de propiedad incorrecto, por lo que ningún mensaje sobrevive al límite del ejecutor. Leer la clave de `Object.keys($input.first().binary)` lo resolvió. ¡Gracias de nuevo! La configuración es más robusta que la que tenía antes, así que valió la pena hacerlo de todas formas. ---
**Author:** ![Cloudrocket](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/cloudrocket/32/188664_2.png) [@Cloudrocket](https://community.n8n.io/u/Cloudrocket)\ **Post date:** [13 Agosto, 2026 09:47 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/16 "2026-08-13T09:47:12Z")
Me alegra que haya funcionado, ¡y gracias por escribir los detalles de vuelta en el hilo! Tus dos advertencias merecen ser repetidas para cualquiera que llegue aquí después. En modo externo, la lista de permitidos que cuenta es la que está en n8n-task-runners.json, y la variable en el contenedor principal se ignora. La falla ERR\_PNPM\_UNEXPECTED\_STORE es la discrepancia de versión principal del almacén que diagnosticaste, así que fijar pnpm con corepack prepare antes de la instalación es la solución correcta, ya que el árbol de ejecución de la imagen base está vinculado al almacén v10. El errorDetails vacío vale la pena entenderlo en lugar de simplemente trabajar alrededor de él. getBinaryDataBuffer lanza un objeto plano en lugar de un Error cuando el nombre de la propiedad es incorrecto, por lo que nada útil sobrevive al límite del ejecutor y obtienes un “Unknown error” desnudo. Leer la clave de Object.keys($input.first().binary) es el patrón duradero, porque el nombre de la propiedad se establece por el nodo que produjo el binario. Una cosa para la próxima vez: mueve la etiqueta n8n y la imagen de ejecutores juntas y reconstruye. La divergencia de versión entre los dos es la misma clase de sorpresa que acabas de resolver. ---
**Author:** ![system](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/system/32/36532_2.png) [@system](https://community.n8n.io/u/system)\ **Post date:** [20 Agosto, 2026 09:48 UTC](https://community.n8n.io/t/code-node-cant-resolve-xlsx-external-module-after-upgrading-to-2-33-4/306603/17 "2026-08-20T09:48:05Z")
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.