.jpg)
En el desenvolupament de programari modern, la gestió de dependències amaga trampes subtils que poden paralitzar un projecte. Un dels errors més emblemàtics és el famós 'Invalid hook call' de React, que sol atribuir-se a un mal ús de hooks, quan en realitat la seva causa més comuna és la duplicació del mateix paquet React a l'arbre de dependències. Aquest fenomen no és exclusiu de React; és una manifestació d'un problema estructural que afecta qualsevol llibreria que utilitzi estat a nivell de mòdul, com contextos, classes de validació o fins i tot singletons interns.
El mecanisme intern de React es basa en un singleton compartit entre react i react-dom a través d'un 'dispatcher' emmagatzemat a l'àmbit del mòdul. Quan una aplicació o una llibreria enllaçada importa React des d'una còpia diferent, aquest singleton mai s'inicialitza, provocant l'error. El mateix passa amb els contextos: si un Provider es crea amb una còpia i un consumidor n'utilitza una altra, el context simplement no comunica, retornant valors per defecte sense cap advertència. Aquests errors silenciosos són encara més perillosos perquè no llancen excepcions; es manifesten com a dades incorrectes que poden passar desapercebudes durant hores.
Les causes d'aquestes duplicacions són variades: conflictes en rangs de versions entre dependències, l'ús de npm link durant el desenvolupament de llibreries, el hoisting en monorepos, o fins i tot el hazard de paquets duals (CJS/ESM) carregats simultàniament. Eines com pnpm, en seguir estrictament el model de peer dependencies, poden generar múltiples instàncies d'un mateix paquet si diferents parts del projecte requereixen versions diferents. Fins i tot en entorns de module federation, és fàcil duplicar React si no es declara com a singleton compartit.
En Q2BSTUDIO, en desenvolupar aplicacions a mida, ens enfrontem a aquests desafiaments diàriament. El nostre equip implementa estratègies proactives com l'auditoria de l'arbre de dependències amb ordres com npm ls, la forçada de resolució única mitjançant resolve.dedupe a Vite o alias a Webpack, i la correcta declaració de peer dependencies a les nostres llibreries. Per exemple, quan treballem en projectes d'intel·ligència artificial o agents IA per a empreses, la duplicació d'una llibreria com TensorFlow o alguna dependència de serialització pot trencar inferències completes. De la mateixa manera, en serveis cloud AWS i Azure, un mòdul duplicat pot provocar errors en invocacions serverless o en la inicialització de contenidors.
La ciberseguretat també es veu afectada: una classe d'error duplicada pot invalidar comprovacions instanceof, obrint potencials vectors d'atac. Per això, als nostres serveis de seguretat i pentesting revisem la integritat de les dependències. Així mateix, en l'àmbit d'intel·ligència de negoci amb Power BI i altres eines, l'estabilitat de les integracions depèn que les llibreries compartides siguin les mateixes al llarg de tota la cadena. Els nostres serveis d'intel·ligència de negoci inclouen la validació d'entorns per evitar aquests errors silenciosos.
la lliçó fonamental és que a l'ecosistema modern, els paquets no són singletons per defecte. Cada resolució de fitxer genera una instància independent de mòdul amb el seu propi estat. Qualsevol llibreria que mantingui estat a nivell de mòdul (un dispatcher, un registre de contextos, una classe per a instanceof) signa un contracte implícit d'unicitat. Quan aquest contracte es trenca, els errors poden ser confusos o silenciosos. A Q2BSTUDIO, entenem que la qualitat del programari a mida passa per dominar aquest tipus de detalls tècnics. Per això, oferim serveis cloud AWS i Azure que inclouen configuracions d'entorns de producció dissenyades per evitar duplicacions, així com acompanyament en l'adopció de bones pràctiques com l'ús de yalc en lloc de symlinks i l'externalització de dependències en bundles.
En conclusió, el bug dels dos React és només la punta de l'iceberg. Conèixer com funciona la resolució de mòduls i aplicar eines de verificació primerenca és essencial per a qualsevol equip que vulgui construir programari robust, escalable i lliure d'errors fantasma. A la nostra experiència, invertir en aquesta comprensió estalvia jornades de depuració i garanteix que les aplicacions —ja siguin d'intel·ligència artificial, business intelligence o automatització— funcionin com s'espera en qualsevol entorn.
