Me encargaron el desarrollo de un paquete NPM con un componente personalizado (en este caso, un componente de reacción) que hace uso de otras dependencias como plate, slate, etc.
Estoy en el proceso de preparar el dist de salida, pero no tengo claro cuáles son las mejores prácticas al hacerlo: ¿Deberían resolverse todas las dependencias y agruparse en un gran archivo .js o esto puede ignorarse? (Estoy usando resolución acumulativa aquí). Me temo que esto produciría un archivo enorme que incluye el origen de todas las dependencias, pero como dije, realmente no estoy familiarizado con el proceso...
Por otro lado, ¿es común NO resolver dichas dependencias y dejar que lo haga el consumidor final del componente? (Solo estoy asumiendo aquí)
Se trata de pros y contras... y lo que es posible. Por ejemplo, React solo puede existir en una versión en un proyecto completo, por lo que nunca debe incluir eso.
Las dependencias que son necesarias pero que no están incluidas deben agregarse como peerDependencies en su package.json y es responsabilidad del consumidor descargarlas. La desventaja de incluir dependencias (como dependencies para que el consumidor las descargue automáticamente) es que el paquete del consumidor puede ser más grande de lo necesario. Aquí se debe tener en cuenta quién lo consumirá; ¿Es para uso interno en su organización o para uso público? ¿Sabes algo sobre el contexto en el que se utilizará? Es mejor no incluir dependencias, ya que contribuirá a un paquete resultante más pequeño para el consumidor, pero si es poco probable que las dependencias dependientes estén presentes en el entorno de compilación del consumidor, también podría agregarlas a su paquete. La situación que desea evitar es que su paquete incluya una versión diferente del mismo paquete que el consumidor ya está usando; entonces el paquete resultante puede contener dos versiones de una gran cantidad de código que potencialmente podría reducirse a una versión (si la versión utilizada por el consumidor y por su paquete son compatibles). Por supuesto, todo esto empeora potencialmente y es más probable con dependencias comunes grandes que con dependencias pequeñas poco comunes.
Un ejemplo: en mi organización usamos Material-UI. Tenemos un paquete con componentes React usando Material-UI que consumimos en otros proyectos. Dado que Material-UI siempre estará presente en los proyectos, es una mala práctica incluirlo en el paquete, aunque impondrá una mayor responsabilidad a los consumidores (nosotros) para alinear diferentes versiones del paquete con cualquier versión de Material-UI. que estamos usando en el proyecto aplicable. Dado otro contexto de consumo, incluirlo en el paquete podría haber tenido más sentido.
En mi opinión, nunca debe agrupar su paquete, ya que hace que sacudir árboles sea más complicado para el consumidor. Esto se aplica a los paquetes esm (cjs no se puede sacudir en árbol). En cjs, por otro lado, es devastador con los paquetes empaquetados, ya que evita que el consumidor realice importaciones más específicas para evitar importar una gran cantidad de código sin usar, por ejemplo.
import Comp from "package/Component"en vez de
import { Comp } from "package"