Estoy probando la configuración de los espacios de trabajo de yarn 2. Creo que lo hice de la forma en que se supone que debo hacerlo, pero cuando ejecuto yarn install desde la raíz, no instala ningún módulo ni crea el enlace simbólico a las dependencias como se esperaba. Tengo la siguiente estructura de carpetas
root/ package-a/ package-b/Cada uno contiene un paquete.json y cada una de las carpetas del paquete contiene un índice.js. Aquí están los archivos package.json
raíz:
{ "name": "yarn-workspaces-poc", "version": "1.0.0", "license": "MIT", "private": true, "workspaces": [ "package-a/", "package-b/" ] }paquete-a:
{ "name": "package-a", "version": "1.0.0", "type": "module", "dependencies": { "cross-env": "5.0.5", "package-b": "workspace:*" } }paquete-b:
{ "name": "package-b", "version": "1.0.0", "type": "module", "main": "index.js", "dependencies": { "cross-env": "5.0.5" } }Aquí están los archivos js
paquete-a/index.js
import test from "package-b"; console.log('testing'); console.log(test());paquete-b/index.js
export default function b() { console.log("From b. You made it!"); } El comportamiento esperado es que cuando ejecuto yarn install desde la raíz, se creará allí una carpeta node_modules. Debe contener el paquete cross-env, así como una carpeta vinculada al paquete-b. Sin embargo, nada se crea. Aquí está la salida del comando:
➤ YN0000: ┌ Resolution step ➤ YN0000: └ Completed ➤ YN0000: ┌ Fetch step ➤ YN0000: └ Completed ➤ YN0000: ┌ Link step ➤ YN0000: └ Completed ➤ YN0000: Done in 0s 96mseditar:
Además, si solo ejecuto el paquete-a para probarlo, este es el resultado:
internal/process/esm_loader.js:74 internalBinding('errors').triggerUncaughtException( ^ Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'package-b' imported from /root/package-a/index.js Did you mean to import package-b/index.js? at packageResolve (internal/modules/esm/resolve.js:655:9) at moduleResolve (internal/modules/esm/resolve.js:696:18) at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:810:11) at Loader.resolve (internal/modules/esm/loader.js:86:40) at Loader.getModuleJob (internal/modules/esm/loader.js:230:28) at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:56:40) at link (internal/modules/esm/module_job.js:55:36) { code: 'ERR_MODULE_NOT_FOUND' }Tuve un problema similar. Resulta que la nueva versión de Yarn no usa node_modules:
https://yarnpkg.com/getting-started/migration#switching-to-plugnplay
https://yarnpkg.com/getting-started/migration#final-notes
Esto es realmente confuso ya que no concuerda con la documentación de los espacios de trabajo... que describe el resultado que usted (y yo) esperábamos: https://yarnpkg.com/features/workspaces
Una vez que haya ejecutado 'instalación de hilo', puede iniciar los servidores como lo hizo antes, pero anteponiendo 'espacio de trabajo de hilo NOMBRE DEL ESPACIO DE TRABAJO'.
así que si normalmente comenzarías así:
rootfolder$ cd package-b package-b$ node index.jsahora ejecutaría esto desde la carpeta raíz:
rootfolder$ yarn workspace package-b node index.jsHay algunas otras cosas que puede necesitar configurar para su IDE, etc. Hay mucha información aquí: https://yarnpkg.com/getting-started/migration#switching-to-plugnplay
Cree un .yarnrc.yml en la raíz de su monorepo,
Añádele la siguiente propiedad:
nodeLinker: node-modules Quizás el cambio más notable con Yarn 2 es el sistema PnP. Di adiós a node_modules
Este es el comportamiento predeterminado a menos que especifique el enlazador node-modules "heredado"
Documentado aquí
Para implementar paquetes por separado, a veces es útil para evitar la elevación de node_modules a la raíz.
Puedes añadir
nmHoistingLimits: workspaces Al .yarnc.yml para garantizar que cada paquete tenga sus dependencias instaladas directamente en el nivel del paquete.
Esto es mucho más robusto que el antiguo noHoist: [*/**] del hilo 1.