Usa paquetes npm comunes y React

Depende de paquetes que no saben nada de Beyond, como React, y entiende cómo se manejan los peers, las versiones y las entradas no compatibles.

  • Disponibilidad: Planificado
  • Evidencia: Ejecución registrada
  • Guía práctica

Estado inicial

Tu aplicación depende de paquetes que no fueron escritos para Beyond. Los paquetes npm comunes son entradas obligatorias del CDN, y React es el caso de referencia.

Cómo se reconoce un paquete

Un manifiesto sin el campo beyond.publication es un paquete npm común:

JSON
{ "name": "react", "version": "18.3.1", "main": "index.js", "exports": { ".": "./index.js" } }

Un campo presente pero no válido es un error, nunca una vuelta a este caso.

Sus módulos públicos son lo que el propio paquete expone: su entrada raíz y las subrutas de sus exports. Un archivo que simplemente existe dentro del paquete no es un módulo público, y no lo puedes direccionar a través del CDN.

Cómo se lee exports

Forma del paquete Tratamiento
exports con claves de subruta, la forma abreviada de la raíz, condiciones anidadas, default, exclusiones null, arreglos alternativos y patrones con un solo * Compatible. Las condiciones se prueban en el orden en que las escribió el paquete. Las condiciones activas son browser o node, import, module, default y el entorno.
Sin exports browser (en forma de cadena, solo para el target de navegador), luego module, luego main, luego ./index.js
Una entrada CommonJS, como en React Compatible. Los nombres exportados se leen de forma estática, siguiendo module.exports = require('./file') por todas las ramas de entorno. La unidad exporta esos nombres y default.
require('bare') dentro de CommonJS Compatible. Se convierte en un import del mismo especificador simple, de modo que un renderizador y la biblioteca de la que es peer comparten un módulo público.
Un paquete que solo ofrece destinos require Se resuelve igualmente; su salida se adapta

Cada módulo público es una unidad. React no se empaqueta dentro de tu código ni se divide más: react y react-dom/client son unidades separadas que se referencian entre sí por sus especificadores públicos.

Agrégalo a tu aplicación

Nombra el paquete en las selections de un registro, con una versión exacta o un rango:

JSON
{
  "selections": [
    { "package": "react", "selection": "^18.3.0" },
    { "package": "react-dom", "selection": "^18.3.0" }
  ]
}

Un rango se resuelve una sola vez, cuando se ejecuta el registro, y la versión exacta queda fijada en el grafo. No se mueve hasta que registres de nuevo.

Un solo React, no dos

Las bibliotecas declaran React como dependencia peer, porque una aplicación debe ejecutar exactamente una copia. Un peer no lo instala el paquete que lo declara: lo proporciona el dependiente más cercano, desde el dependiente directo hasta tu aplicación, que depende de él. Su rango restringe la versión que elige ese proveedor, así que react@* junto con un renderizador que exige ^18.3.1 selecciona la 18. Tu renderizador y cada biblioteca que usa React se vinculan a la misma versión. Un peer obligatorio sin satisfacer hace fallar el registro; los peers nunca se instalan automáticamente, porque eso ocultaría un conflicto que necesitas ver antes de publicar. Puedes ver el resultado antes de preparar nada:

  • las aristas del grafo registran cada vinculación de peer;
  • una diferencia de grafos enumera los peers que cambiaron (changed) o están en conflicto (conflict).

Cuando dos partes del grafo necesitan de verdad versiones distintas de un paquete, la resolución las mantiene separadas con scopes. Eso es correcto para bibliotecas comunes e incorrecto para React, así que trata un conflict de peer en react como algo que hay que corregir con una selección o un override, no como algo que se pueda publicar.

Límites

Los paquetes públicos siguen siendo públicos cuando tu aplicación es privada: react se entrega públicamente, bajo su propia URL, a todo el mundo.