Cómo usar componentes privados de tu sistema de diseño en v0

v0 ya puede usar la biblioteca privada de componentes que tu equipo ya pagó por crear. Así, un prototipo puede partir de los componentes reales del sistema de diseño en vez de usar copias que los ingenieros tendrán que sustituir después. Vercel habilitó esta vía de acceso a las 17:00 UTC del 18 de septiembre de 2026: proporciona a v0 un NPM_TOKEN o un NPM_RC mediante una variable de entorno compartida de Development o Preview, y podrá instalar el paquete sin mostrarle la credencial al modelo ni escribirla en el sistema de archivos del sandbox.

El cambio es pequeño; el traspaso, no

Un paquete privado de npm es código JavaScript o TypeScript distribuido a través de un registro que comprueba quién tiene permiso para descargarlo. Los equipos recurren a estos paquetes para compartir componentes del sistema de diseño, tokens, utilidades de autenticación, capas de analítica y herramientas internas.

Hasta ahora, la comprobación del registro interrumpía por completo el flujo de trabajo de v0. Un paquete público podía instalarse con normalidad. Para usar una biblioteca privada de componentes había que buscar una alternativa, como subir un archivo comprimido, o crear el prototipo con componentes nuevos que se parecieran lo suficiente para aprobar la revisión. La segunda opción parecía rápida durante la demostración, pero dejaba pendiente todo un trabajo de sustitución cuando el código llegaba al repositorio real.

La nueva vía de v0 lleva la autenticación al perímetro del sandbox. v0 ejecuta el gestor de paquetes que ya utiliza el repositorio dentro de Vercel Sandbox. Cuando la solicitud de instalación sale hacia el registro privado, Vercel aplica la credencial en el límite de la red. Ni el modelo ni el agente pueden leer su valor, y este tampoco se guarda en un archivo .npmrc local.

La diferencia es importante: el paquete entra en la compilación; el secreto no entra ni en el prompt ni en el sistema de archivos.

Poder acceder al paquete no le enseña a v0 cómo debe utilizar el sistema. Puede obtener un componente Button y aun así elegir la variante equivocada, omitir un provider o pasar por alto el wrapper del tema. Por eso, el paquete debe ir acompañado de documentación vigente, ejemplos y una aplicación real que ya lo consuma. El enfoque más amplio descrito en Cómo proporcionar un sistema de diseño a los agentes de programación sigue siendo válido: el código aporta mecanismos repetibles y las guías aportan criterio.

En el presupuesto del sistema de diseño pesa la sustitución de componentes

La consecuencia para el negocio no es que el paquete se instale más rápido. Es la posibilidad de eliminar una reconstrucción adicional entre la aprobación del prototipo y el trabajo de producción.

Cuando v0 inventa un componente parecido al real, el prototipo y el producto adquieren identidades distintas. Ingeniería tiene que sustituir imports, reasignar props, restaurar el contexto del tema, volver a probar los estados y explicar por qué cambió la pantalla aprobada. Si v0 empieza con el paquete auténtico, el traspaso puede centrarse en revisar y perfeccionar en lugar de reconstruir.

Este es un supuesto práctico, no un benchmark de Vercel. Imaginemos que antes cada prototipo exigía 4 horas para sustituir componentes y que el equipo valora la hora de ingeniería en $100. Si configurar y validar la credencial lleva 1 hora, el ahorro estimado es de 3 horas, es decir, $300.

Ese ahorro no está garantizado. Un paquete mal configurado, un provider ausente o unas instrucciones de uso deficientes pueden consumir esas mismas 3 horas en otro punto del proceso. Mide el diff del repositorio y el tiempo de corrección con uno de tus componentes; después, conserva o descarta el flujo de trabajo según el resultado.

Los equipos que solo utilizan paquetes públicos no notarán ningún cambio. Tampoco los que crean pantallas conceptuales desechables que nunca llegarán a un repositorio. La novedad resulta especialmente relevante cuando se espera que un prototipo aprobado en v0 termine convertido en software mantenido.

Elige la credencial según dónde esté alojado el paquete

La regla sencilla es usar NPM_TOKEN para paquetes privados de registry.npmjs.org y NPM_RC para definir el enrutamiento. No añadas ambos como respaldo. La documentación sobre dependencias privadas indica que NPM_RC prevalece cuando los dos están presentes; así, una configuración personalizada desactualizada podría ocultar un token de npm válido.

Configúralo con el permiso mínimo necesario

1. 1

   Elige un paquete real

   Empieza por un componente que ya se utilice en el repositorio de producción. De ese modo tendrás un import conocido, un resultado visual conocido y un traspaso real que examinar. Un paquete creado solo para una demostración confirma que la autenticación funciona, pero no demuestra que el flujo elimine trabajo repetido.

2. 2

   Crea la variable compartida

   En Vercel, selecciona el equipo, abre Settings y después Environment Variables. Añade NPM_TOKEN o NPM_RC como variable compartida y asígnala a Development, Preview o ambos entornos. Márcala como sensible.

   La documentación de v0 exige un rol Developer de Vercel o superior para administrar esta configuración. El token debe tener acceso de lectura a todos los paquetes privados que instala el proyecto, sin permisos más amplios de los que requiera el registro.

3. 3

   Configura la ruta de un registro personalizado

   Para GitHub Packages, Vercel documenta este valor de NPM_RC para el scope de ejemplo @acme:

   @acme:registry=https://npm.pkg.github.com/
   //npm.pkg.github.com/:_authToken=${GITHUB_PACKAGES_TOKEN}

   Guarda GITHUB_PACKAGES_TOKEN como otra variable compartida. Durante la instalación, NPM_RC puede expandir referencias ${VAR} y aplica al valor referenciado la misma protección que a la credencial. Para JFrog Artifactory, utiliza la URL del registro y la variable del token equivalentes.

4. 4

   Comprueba la integración de v0

   En v0, abre Settings, entra en Integrations y busca npm. v0 enlaza automáticamente las variables compartidas compatibles. Pídele que instale y renderice el componente elegido; después, confirma que la vista previa utiliza los estilos, el provider y el comportamiento esperados.

5. 5

   Revisa el traspaso al repositorio

   Envía el resultado al repositorio real. Revisa package.json, el lockfile, la ruta del import, la configuración del provider, los estilos globales y el diff del código fuente. Ejecuta las comprobaciones que ya utiliza el repositorio. Una vista previa funcional aporta evidencia, pero el traspaso solo termina cuando la rama sigue utilizando correctamente el componente aprobado.

Cuatro equipos que pueden aprovecharlo desde mañana

Un equipo de producto SaaS que crea un panel de control

La persona responsable del diseño de producto puede prototipar un nuevo flujo de facturación con los mismos componentes privados que ya publica el equipo de frontend. La ventaja no es obtener una generación más bonita, sino revisar y aprobar el comportamiento real de Button, Table y Modal, y terminar con un diff de código menor.

Un responsable del sistema de diseño que prepara v0 para la empresa

Antes de una importación de Design Systems 2.0, el responsable puede añadir el paquete privado y proporcionar a v0 el repositorio de origen, una aplicación real que ya lo consuma y la documentación de uso vigente. v0 crea una base inicial y se detiene para que se revise antes de guardar el sistema. Así se pueden detectar una sola vez las fuentes, los providers, los tokens y los patrones de componentes obsoletos, antes de que todos los chats posteriores los hereden.

Un responsable de plataforma en una agencia con varios registros

La agencia puede recurrir a NPM_RC para dirigir los scopes de cada organización al registro adecuado, en lugar de copiar un token en cada prototipo. El resultado es una configuración de credenciales controlada y menos imitaciones específicas para cada cliente. Aun así, la agencia necesita límites de acceso independientes y un proceso de revisión para el paquete de cada cliente.

Un equipo de frontend empresarial que usa GitHub Packages o JFrog

El equipo de plataforma puede permitir que v0 instale las mismas dependencias internas que utiliza el repositorio importado. Así, la vista previa es más fiel: los problemas con la resolución de paquetes, la configuración del tema y los imports aparecen durante el prototipado, no después del traspaso. Si la política impide compartir credenciales, la vía documentada con .tgz sigue siendo la prueba piloto más acotada.

El acceso y el precio son dos cuentas distintas

La documentación sobre paquetes privados no exige un plan de pago de v0 concreto ni un complemento independiente para esta función. Lo que sí establece es un requisito de permisos: quien administre la variable compartida debe tener un rol Developer de Vercel o superior. La documentación de roles de Vercel sitúa el rol Developer del equipo en los planes Pro y Enterprise.

Esto es independiente de los planes actuales de v0. Free cuesta $0 al mes, incluye $5 en créditos mensuales y limita el uso a 7 mensajes diarios. Plus cuesta $30 por usuario al mes e incluye $30 en créditos mensuales por usuario y $2 en créditos diarios por usuario al iniciar sesión. Business cuesta $100 por usuario al mes, ofrece las mismas cantidades de créditos publicadas y desactiva de forma predeterminada el uso de datos para entrenamiento. Enterprise tiene un precio personalizado. La documentación aún menciona un plan Premium anterior de $20 al mes, pero se está retirando y ya no admite nuevos usuarios.

Vercel Pro tiene una tarifa de plataforma de $20 al mes, un puesto con capacidad de despliegue y $20 en créditos de uso mensuales. Cada puesto adicional de Owner o Member cuesta $20 al mes. Todos estos precios publicados están expresados en dólares estadounidenses antes de impuestos.

Como ejemplo, un puesto de v0 Plus más la tarifa de plataforma de Vercel Pro suman $50 al mes antes de impuestos y consumo. Ese importe no es el precio mínimo de esta función. La documentación del lanzamiento no afirma que sean obligatorios ambos planes de pago, así que conviene revisar la cuenta y el rol actuales antes de contratar una mejora.

Los límites, sin rodeos

El acceso a paquetes privados elimina una barrera. No convierte una biblioteca de componentes en un sistema de diseño completo, no hace que el código generado esté listo para producción ni mantiene actualizado un proyecto existente cuando cambia el paquete.

Hay límites prácticos:

• Las Shared Environment Variables no admiten valores específicos por rama.
• NPM_RC prevalece sobre NPM_TOKEN cuando ambos están presentes.
• El token debe cubrir todos los paquetes privados que instala el proyecto, incluidas las dependencias privadas que arrastre el paquete elegido.
• La credencial puede estar protegida y, aun así, la implementación generada ser incorrecta.
• Los providers, el CSS global, las fuentes, los tokens, los estados de los componentes, las pruebas, la accesibilidad y la revisión siguen formando parte del traspaso.

La promesa de seguridad es acotada y valiosa: v0 no muestra la credencial al modelo ni al agente, y tampoco la escribe en el sistema de archivos del sandbox. La empresa sigue teniendo que decidir si permite usar un token del registro en este flujo de trabajo, qué alcance mínimo debe tener y cómo se rota.

Qué hacer el lunes

Actúa esta semana si el equipo ya cuenta con un paquete privado de componentes y los prototipos de v0 se convierten con frecuencia en trabajo de repositorio. Espera si la persona responsable de seguridad todavía no ha aprobado una credencial de solo lectura para el registro. Si no se pueden compartir credenciales, utiliza la vía .tgz para una prueba piloto acotada. Ignora esta novedad si solo trabajas con paquetes públicos o si el trabajo en v0 termina en conceptos desechables.

El lunes, importa un componente privado real. Coloca la credencial de solo lectura con el menor alcance posible en Development, confirma la integración de npm, pide a v0 que renderice el componente y traspasa el resultado al repositorio. Revisa la dependencia, el lockfile, el import, el provider, el estado visual y el diff del código fuente. Si ese componente supera el traspaso sin que haya que sustituirlo por una imitación, el flujo de trabajo habrá cambiado. Entonces mide las horas antes de ampliarlo.

Para conocer el próximo cambio práctico de plataforma y las cifras de negocio que lo acompañan, suscríbete al boletín.