JSR: Construyendo un Registro Abierto para la Comunidad de JavaScript

Hola, y bienvenidos a JSR, construyendo un registro abierto para la comunidad de JavaScript. Así que, para empezar, soy Leo. Trabajo en Deno, y también soy un mantenedor de JSR. Así que quiero ver rápidamente un mar de manos cuántas personas saben qué es JSR. Bien, alrededor de un tercio. Justo. Bien, bien.

Entonces, para los otros que no saben, primero déjenme presentarles. ¿Qué es JSR? Entonces, JSR es un nuevo registro de JavaScript. Es similar a NPM, pero no es NPM. Soporta TypeScript de forma nativa, lo cual no es solo una característica. Fue una decisión técnica fundamental que queríamos tener, porque TypeScript está en todas partes ahora, y publicar TypeScript en NPM es un poco complicado. Entraré en eso en un momento.

Y luego, bueno, como dije, no reemplaza a NPM. Vive junto a él. Así que aún puedes usar tus paquetes de NPM cuando tengas dependencias en JSR. Y es compatible con diferentes entornos de ejecución. Así que puedes usarlo con trabajadores de Cloudflare, Deno, Node.js, Bun, y cualquier otra cosa que soporte directorios de módulos de Node. Y también tiene soporte integrado por YARN NPM-PM, recientemente, pero no NPM, lo cual nos gustaría cambiar. Y otro punto de característica es que JSR es completamente gratuito y de código abierto. Entonces, ¿por qué construimos JSR? Bueno, la primera razón es la complejidad. Nuevamente, publicar en NPM puede ser un poco demasiado complicado. Tienes que configurar TS config, tienes que encontrar las configuraciones correctas, el objetivo, etcétera. No debería ser así. Es demasiado complicado. Y solo queríamos que funcionara. Oh, ups. Luego tenemos la innovación. NPM ha dejado de agregar nuevas características, realmente. Quiero decir, ¿alguna vez has visto algún cambio reciente en NPM? No.

La característica más reciente, creo, fue hace como dos años, fue algo. Pero algo reciente, no ha habido, porque han dejado de innovar. Y el ecosistema de JavaScript no se adapta a eso. El ecosistema de JavaScript evoluciona constantemente. Hay un nuevo framework como cada semana. Y el ecosistema en sí se está moviendo rápido. Pero el registro en el que vive no se está moviendo en absoluto, lo cual es completamente inaceptable.

Y luego nuestros valores, a diferencia de NPM, que es propiedad de Microsoft, JSR es completamente abierto. Y es de código abierto, está impulsado por una comunidad, y tiene gobiernos abiertos como principio fundamental. Así que algunas características adicionales son la autenticación sin tokens, para que puedas publicar desde GitHub actions sin tener que configurar ningún token. Simplemente usará OIDC y verificará con tu usuario de GitHub. Procedencia, para que pueda probar que la persona que lo publicó realmente es la persona que lo publicó. Así que puede probar que fue ese individuo.

Y generación de documentación. Genera documentación para ti automáticamente basada en tus typings y comentarios de JS doc, etcétera. Y también hay muchas más características en las que no necesariamente voy a entrar en detalles. Pero tiene métricas de descarga muy detalladas y algunas cosas más que quizás podamos ver más tarde. Ahora, el gobierno.

JSR es abierto por la razón de que JavaScript está controlado, no controlado por una empresa, por un comité, también conocido como T39. Luego, todas las implementaciones de JavaScript son de código abierto, como V8, JS core, etcétera. Y luego NPM es de código cerrado. La única parte de código abierto es el CLI, creo. Pero el registro real es completamente de código cerrado y solo tiene niveles de pago para tener paquetes privados, etcétera. Y está dirigido por una empresa. Y eso no encaja con el resto del sistema de JavaScript. Y por lo tanto, el registro de JavaScript necesita ser de código abierto y gobernado por una comunidad. Y abierto a la innovación y ser dirigido por un comité de algún tipo.

Entonces, ¿quién está dirigiendo esto? Bueno, tenemos algunas personas. Y para dirigir un proyecto como este, tienes que construir confianza. Y una gran parte de lo que se necesita fue convencer a líderes independientes respetados de todo el ecosistema. Quiero decir, necesitas tener una fundación para convencer a más personas de poder hacer de esto algo que realmente funcione. Y como tal, tenemos algunas personas que se unen a la junta de gobierno. Y esto demuestra nuestro compromiso de ser realmente un proyecto comunitario.

Así que las personas son Evan Yu, el creador de Vue.js y Vite y fundador de Void Zero. Luego tenemos a Isaac Schluter, el creador de NPM y cofundador de VLT.sh. Luego tenemos a James Snell, quien es miembro de Node.js y el ingeniero principal de sistemas en Cloudflare. Luego tenemos a Luca Casanato, quien es un colega mío que trabaja en Deno y también es miembro de TTC39. Y finalmente, tenemos a Ryan Dahl, quien es el creador de Node.js y Deno. Y eso abarca a nuestros miembros actuales de la junta, pero en el futuro, podríamos tener más en la junta.

Pero la junta realmente solo hace algunas cosas, que son supervisar que GSR se mueva a una fundación. Entraré en eso en un momento. Y luego establecer la dirección general del proyecto. Tomar decisiones en nombre del proyecto cuando sea necesario. Así que realmente, esto es cuando hay algún conflicto de intereses o hay una decisión drástica cambio que queremos movernos a un proveedor diferente para nuestra infraestructura, etc. Y determinar cómo se recoge la gobernanza en el futuro. Así que si queremos más personas, esto aún no se ha decidido realmente solo porque estamos actualmente contentos con las cinco personas que tenemos. Y luego determinar cómo se hacen las contribuciones de código abierto al proyecto. Actualmente, realmente no tenemos una política. Es más como, sí, esto se ve bien. Voy a fusionarlo. Pero no tenemos reglas estrictas sobre cómo queremos ejecutar este proyecto. En cuanto a qué tipo de contribuciones queremos aceptar, qué no. Actualmente, realmente es solo caso por caso que decido, sí, vamos a fusionar esto. O cualquier otro de los mantenedores, es decir.

Así que también tenemos un grupo de moderación. Así que nuevamente, GSR es público y es una infraestructura pública. Así que como muchos otros espacios públicos, no NPM por ejemplo, pero en el caso de GSR, necesita mantenimiento y reglas de seguridad. Así que tenemos un grupo de personas que maneja cualquier tipo de aspecto humano. Así que reaccionar con personas que tienen problemas, hay una disputa de nombres, hay informes de seguridad, aplicación de políticas, cosas así. Es muy moderador, todo el sistema. Y esto obviamente es bastante importante. Pero a la gente generalmente no le importa. No es un trabajo muy agradecido. Es relativamente ingrato. Y parte de lo que se necesita para mantener el registro funcionando de manera segura y confiable para todos. Así que para eso tenemos a Oliver Methurst, quien es creador de POP4, que es otro motor de JavaScript. Luego tenemos a Augustin Mori, quien es un contribuidor de Node.js y GSR también. Y luego tenemos a Dr. slash Blackerslight, contribuidor de GSR.

Estas son personas en las que confiamos. No se trata realmente de conseguir personas que sean populares o famosas, sino realmente personas que estén dispuestas a hacer el trabajo arduo de responder a los tickets de soporte y tener que lidiar con cualquier tipo de problema.

Luego, como mencionaba, estamos hablando de movernos a una fundación. Entonces, ¿qué es esta fundación? Bueno, idealmente queremos movernos a una fundación abierta donde GSR, porque GSR es actualmente propiedad de la empresa Dino, lo cual va en contra de lo que representa GSR.

Queremos moverlo a una fundación abierta que pueda encargarse de ello, encargarse de los costos también parcialmente, y simplemente tener como una plataforma que demuestre que realmente somos abiertos y no propiedad privada. Así que hemos estado hablando bastante con OpenGS. Y eso va bastante bien.

Pero veremos qué sucede y también ECMA parece tener algún interés. Pero en general, es un proceso lento. Así que veremos qué sucede.

Ahora, una alternativa también sería que simplemente tengamos nuestra propia fundación. Así que más bien una empresa sin fines de lucro abierta. Ese es también un enfoque que hemos estado pensando en hacer. Está un poco menos definido y no estamos completamente seguros de si vamos a hacer eso.

Tiene sus diferentes problemas, como que tienes que encargarte de las cuestiones legales tú mismo en lugar de que OpenGS se encargue de todos los asuntos legales. Así que veremos exactamente qué hacemos. Pero crear nuestra propia organización sin fines de lucro técnicamente es el enfoque más rápido, y no tener que esperar los procesos de estas otras organizaciones. Pero veremos exactamente qué va a suceder. Es un proceso lento en general, independientemente del enfoque que tomemos.

Y trataremos de impulsar esto hacia adelante. Pero sí, vendrá como venga. Pero ya se está tratando como algo abierto.

Entonces, veamos algunas de las características recientes y futuras de JSR. Así que mencioné algunas de las características clave al principio. Pero algunas características adicionales que agregamos recientemente fueron métricas de descargas relativamente detalladas. Así que cuando vas a npm, lo máximo que ves son las descargas semanales en un pequeño fragmento.

Con JSR, puedes ver el desglose real de todas las versiones de cuánto tiempo han estado teniendo descargas. Así que puedes cambiar entre diario, mensual y semanal. Y en algún momento, también agregaremos anual, pero eso actualmente es irrelevante. Y luego también hemos agregado recientemente el modo oscuro. Quiero decir, la gente lo ha estado pidiendo, así que simplemente lo hicimos. Fue hace bastante tiempo. Pero no es realmente una característica clave, pero la gente lo pide, así que lo damos.

Y luego cambiamos un poco nuestra infraestructura de archivado de paquetes, porque en JSR, no puedes cambiar las cosas, realmente. No puedes eliminar paquetes existentes. No podemos tener una situación de left-pad de nuevo. Así que la idea es que sea inmutable. Así que si publicas en JSR, tu paquete está ahí. Solo eliminaremos cosas en caso de disputas legales o cualquier otro tipo de situación relativamente similar. O estamos trabajando en agregar también la capacidad de poder tú mismo eliminar una versión de paquete si tiene menos de diez descargas y fue publicada hace menos de dos horas.

Queremos dar a las personas la flexibilidad de eliminar los paquetes bajo ciertas circunstancias. Pero no siempre, porque, de nuevo, left-pad, no queremos repetir. Así que nada puede ser eliminado, pero tenemos archivado. Así que como en GitHub, puedes archivar un paquete, y eso simplemente lo eliminará de la búsqueda, no lo hará visible. Pero todavía está ahí. Así que puedes descargarlo. Y eso es relativamente todo para las características más recientes. Y luego tenemos algunas características futuras, que es nuestra búsqueda renovada. Así que esto también va desde rehacer nuestra búsqueda actual para que sea un poco más fácil de usar y un poco más agradable.

Pero también esto añade búsqueda de símbolos a nivel de scope. Así que en GSR, cada paquete está bajo un scope, a diferencia de NPM, donde eso es relativamente opcional. Y actualmente, puedes buscar símbolos, también conocidos como clases de funciones, etcétera, de un paquete en un paquete. Pero existe el caso de uso. Por ejemplo, tenemos el scope add STD, que es un scope de biblioteca estándar que proporciona varias funcionalidades. Pero no quieres pasar por cada paquete y encontrar cuál tiene la funcionalidad correcta. Así que vamos a añadir una búsqueda que te permitirá buscar cada función, cada clase, cada interfaz en ese scope.

Pero luego vamos a mejorar eso, y vamos a añadir funcionalidad para buscar cualquier función, cualquier clase, cualquier cosa en todo el registro. No importa qué scope, qué paquete, puedes simplemente buscar en una búsqueda global, y obtendrás resultados. Similar a Go, según creo. Y luego también una característica más en la que queremos trabajar pronto es la generación de changelog y diff. Esto suena bastante aburrido, que solo generamos un changelog, como ves en GitHub. Pero no, esto realmente te daría un buen diff entre funciones previamente cambiadas.

Así que digamos que la versión 1.0 y 2.0 tienen algunos cambios de firma. Mostrará eso como, oh, esto cambió. Y verás un buen diff que te permitirá comparar cuáles fueron los cambios, haciendo las migraciones a nuevas versiones mucho más fáciles. Y eso es prácticamente todo en lo que estamos trabajando actualmente y queremos implementar pronto. Así que supongo que podemos echar un vistazo rápido a JSR. Déjame ver si puedo hacer que esto funcione. Ahí vamos. Así que queremos ir a, oh, Dios, mi portátil está siendo muy lento. Ahí vamos. Así que este es el sitio web de JSR. Parece relativamente aburrido. No hay mucho que ver. Tenemos algunas publicaciones de blog aquí. Tenemos paquetes destacados, que seleccionamos manualmente qué paquetes queremos destacar, recientemente actualizados, y nuevos paquetes para JSR.

Luego tenemos básicamente puntos principales similares a los que mencioné anteriormente. Pero podemos echar un vistazo a un paquete popular. Así que puedo ir a at STD. Nuevamente, como mencioné justo ahora, es un scope de biblioteca estándar donde proporcionamos varias funcionalidades estándar. Esto es mantenido por la empresa Dino. Y podemos simplemente saltar a la colección y veremos algunas cosas interesantes. Es lo suficientemente grande.

Bien. Bueno, tenemos este trabajo que muestra con qué entornos de ejecución es compatible. Esto es decidido por los mantenedores. No automáticamente porque detectarlo automáticamente es relativamente complicado. Y luego también tenemos una puntuación. Así que JSR puntúa tu paquete porque a la gente le encanta jugar con cosas. Y las puntuaciones se basan en varias piezas de información diferentes, como si tienes documentación sobre tus símbolos, si tienes una descripción para tu paquete, si elegiste algún entorno de ejecución con el que sea compatible, etcétera, etcétera. Y vamos a añadir más con el tiempo. El objetivo de la puntuación no es realmente oh, este paquete es mejor que aquel, sino se trata más de hacer que la gente use buenas convenciones y cree mejores paquetes para todo el ecosistema. Luego tenemos las métricas semanales, como vemos esto es muy similar a npm, pero puedo hacer clic en eso y verás un bonito gráfico para esto es semanalmente para este paquete.

Puedes cambiar esto a mensual si quieres. Y bien. Mi portátil está siendo extremadamente lento en este momento. De todos modos.

Y una característica más que puedo mostrar rápidamente no está en este paquete. Pero tenemos una lista de dependencias. Pero además de una lista de dependencias, puedes generar, generamos para ti un gráfico de dependencias. Así que creo que assert depende de un paquete. Bien. Eso es inútil. Pero podemos ir a eso, por ejemplo, y ves una lista de dependencias, pero también puedes ir a un gráfico de dependencias, y generalmente generará un gráfico. Sí. Ahí vamos. Que genera todas las dependencias para los archivos internos del paquete. Pero también en amarillo resalta paquetes como dependencias externas a un paquete diferente. Y en rojo también resaltará cualquier paquete npm. Ahora no tengo un ejemplo directo para eso. Pero sí. Eso es eso.

Y creo que nos queda un minuto que puedo dar rápidamente una visión general de la generación de documentación. Así que aquí tenemos la biblioteca assert. Tiene varios símbolos. Tenemos un punto de entrada predeterminado y tenemos la función assert. Y esto es generado este contenido es generado por los comentarios JS doc a través de los comentarios JS doc y genera tipo como lo que acepta, alguna documentación, ejemplos, como parámetros definidos, tipos de retorno, etcétera. Así que ofrece un desglose completo, y también te muestra cómo usar esto. Así que puedes ejecutar un comando para agregarlo o puedes seleccionar el sistema que desees. Lo recordará para ti. Así que puedes ir a pnpm y te muestra cómo usarlo con pnpm, etcétera. Y sí. Eso es prácticamente todo para JSAR.

Y sí, tenemos reuniones semanales, quincenales, reuniones abiertas, puedes unirte. Puedes ir al enlace. Habrá una invitación en el calendario. Y puedes ir a JSAR.io para usar JSAR. Y también tenemos, bueno, es de código abierto, así que por favor contribuye. Hay muchas correcciones simples que están marcadas como good first issue. Así que nos encantarían algunas contribuciones al proyecto. Gracias.

Entonces, primero, ¿JSAR ha soportado paquetes privados ya? Actualmente no soportamos paquetes privados por ahora. No es difícil para nosotros soportarlo, pero es solo otra característica que queremos. Tenemos un rastreador de problemas relativamente largo con muchas solicitudes de muchas características, y hay mano de obra limitada. Así que en algún momento, va a llegar, pero no ahora.

¿Hay algún lugar donde puedan verificar eso? Como, ¿cuándo planean trabajar en eso? Sí, de hecho tenemos un tablero de proyectos para JSAR. Es público. Si vas al repositorio de JSAR, debería haber un enlace en algún lugar para el tablero de proyectos y puedes ver las prioridades de todo y en qué se está trabajando, qué tan difícil es, etcétera. Lo hemos caracterizado todo.

Y están interesados en mudarse a JSAR. Y el obstáculo para eso es que NPM CLI soporte JSAR. Así que eso es algo que vamos a intentar impulsar. Ver que el equipo de NPM nos va a permitir agregar soporte nativo a NPM para JSAR. Pero sí. Suena emocionante.

Sí. Ok, Dominika está preguntando, ¿es posible autoalojar un espejo de JSAR? Entonces sí y no. Así que autoalojar JSAR es factible. Necesita algo de configuración. Actualmente tienes que configurar como GCP y AWS y todas esas cosas de infraestructura tú mismo, pero definitivamente es autoalojable.

Queremos hacer este flujo mucho más fácil para las personas, y también queremos agregar espejeo de tal manera que puedas tener una instancia de registro de JSAR como proxy. Así que básicamente puedes tener tu propio privado, digamos que lo usas en tu empresa, y luego volverá al normal para cosas que no existen en tu privado. Es algo que queremos hacer, pero aún por hacer. Tantas cosas por hacer. Es un gran proyecto.

Es bueno que estés trabajando en ello. Y la siguiente pregunta, ¿están tomando medidas para aumentar la diversidad en el grupo de gobernanza o equipo de moderadores? No hemos hecho ningún esfuerzo específico en eso. Simplemente porque queríamos comenzar con un equipo de personas que ya conocemos, y personas que son, bueno, bien conocidas por la comunidad. Quiero decir, espero que la mayoría de la gente conozca a esas personas en la junta. Así que definitivamente aumentaremos la diversidad del equipo. Pero ahora mismo, nos estamos enfocando en simplemente hacer las cosas, y luego veremos cómo mejorar esto. Quiero decir, probablemente vamos a mejorar esto también de antemano, pero sí, definitivamente es algo que haremos. Esperemos que sí.

¿Realizan alguna detección de virus o daños en los paquetes? Nuevamente, otra característica que tenemos en el seguimiento de problemas y que no hemos tenido la oportunidad aún. Es una de alta prioridad, porque si no puedes estar seguro de que algo es seguro en GSR, entonces quiero decir, obviamente, eso va a causar problemas. Así que definitivamente es algo que vamos a hacer. Estamos pensando en cómo podemos hacer esto exactamente. No es demasiado difícil. Solo necesita sentarse, como cualquier otra característica. Lo vamos a hacer. Esperemos que puedan solucionarlo adecuadamente.

¿Pueden usarse los paquetes de GSR en una base de código que no sea de TypeScript? Sí. Básicamente, puedes depender de los paquetes de GSR en cualquiera de tus proyectos de Node, si quieres, y de hecho hacemos la traducción por ti. Así que generamos archivos JavaScript y los mapas de origen correctamente, y cuando NPM o PMPM o YARN descargan el paquete, lo obtendrás transpilado, mientras que cuando lo usas con Deno, Deno simplemente extraerá los archivos individuales directamente. Es ligeramente más eficiente, pero al final, obtienes el mismo resultado. Bien.

Sí, otra pregunta con muchos likes y respuestas, de hecho. ¿Tienes la sensación de que JSON5 será alguna vez compatible con Package.JSON, o cualquier otro comando de soporte de formato similar? No sé sobre Package.JSON. Quiero decir, tenemos nuestro propio archivo de configuración, que es GSR.JSON, que tiene cuatro campos, que son el nombre del paquete, la versión, los puntos de entrada y la licencia, y eso es compatible con JSON C. Pero para Package.JSON, sí, eso es... Pregunta al equipo de NPM. Bien.

¿Cómo se ve el Package.JSON de un paquete publicado? ¿Todavía tiene campos de exportación de modelo principal? Bueno, creo que acabas de responder eso. Sí, entonces tenemos un GSR.JSON que tiene un campo de exportaciones donde puedes especificar una cadena o un objeto. Una cadena es el punto de entrada predeterminado, y de lo contrario, puedes hacer algunos escenarios con el objeto también para hacer un punto de entrada predeterminado o puntos de entrada adicionales que desees. Pero todo lo que quieras importar de GSR tiene que estar especificado en los puntos de entrada. Así que sí. Bien.

Y preguntan si hay un camino de migración rápido o tal vez una guía. Quiero decir, una cosa con GSR que olvidé mencionar es que es solo ESM. Así que no soportamos CJS. Y eso es por varias razones diferentes, pero también porque ESM es el futuro. Más paquetes se están moviendo a ESM y se usa menos CJS. Así que el camino a seguir, o más bien, el camino de migración de NPM a GSR debería funcionar con tal vez algunos pequeños ajustes. Si estás usando CJS, entonces tendrás que cambiar bastantes cosas para usar ESM en su lugar. Pero en general, debería funcionar. Si hay algún problema, quiero decir, solo abre un problema. Y como el CLI tiene... Como tenemos un GSR CLI que puedes usar para publicar en GSR y te da mensajes de error relativamente útiles. Así que si eso no ayuda, entonces sí, abre un problema, por favor. Genial. Entonces tienen un camino a seguir seguro. ¿Cómo piensas reducir el problema de que el scope en NPM es mantenido por una persona diferente? Esto podría ser un problema de seguridad. ¿El scope en NPM es mantenido? No estoy seguro de entender. Hay un problema en NPM, supongo. Dice que el scope en NPM es mantenido por una persona diferente.

Oh, I see. Creo que entiendo cuál es el problema. Creo que lo que están preguntando es sobre, digamos, tengo el scope STD, por ejemplo, pero alguien más quiere publicar en él también. Creo que probablemente sea eso. Y si no es eso, lo siento, pero voy a responder a esto. Si, digamos, alguien está ocupando un nombre de scope, como, digamos, yo, por ejemplo, tengo el scope de Google, aunque no trabajo en Google y no me pertenece, nosotros lo transferiremos a la empresa Google. Si hay un scope que realmente se está utilizando y está nombrado, como, no pertenece a la persona real, entonces aún veremos moverlo a los propietarios correctos. Así que tendremos discusiones con el actual mantenedor de él, veremos por qué tienen ese scope, si tienen una razón suficientemente válida, entonces hablaremos de nuevo con las personas que quieren el scope e iremos de un lado a otro. Pero hasta ahora, todos han sido simplemente, oh, sí, esta empresa quiere el scope, sí, se lo daremos a ellos. No han tenido ningún problema. Y también hemos reservado los 500 paquetes principales más algunos más y otras empresas como scopes reservados, por lo que no puedes simplemente crear los scopes. Tendrás que recibirás un popup cuando intentes registrar esos scopes y dirá, por favor abre un ticket. Y luego te lo asignaremos porque, por ejemplo, no queremos que personas al azar estén simplemente creando, como, en Discord y luego tener cosas raras o como en Google o lo que sea. Así que nos encargaremos de eso. Así que no puedes simplemente ocupar nombres y hacer cosas que otras personas no deberían estar haciendo. Tiene sentido. Quiero decir, eso podría ser un gran puente.

¿Algún plan para uso empresarial? Así que como mencioné antes, el tema del proxy es probablemente la clave para las empresas para que puedas auto-hospedarte en tu empresa y tener un flujo de regreso al registro principal. Y supongo que los paquetes privados también entran en el uso empresarial, hasta cierto punto. Y sí, no lo tenemos todavía. Pero en algún momento no es difícil, pero de nuevo, sí, llegaremos a eso. Necesitas tiempo. Quiero decir, de nuevo, por favor contribuyan. Nos encantaría algo de ayuda. Es bueno que puedan contribuir entonces.

¿Están planeando lanzar una herramienta CLI también? Sí, así que tenemos un JSR CLI que puedes usar a través de MPX. MPX JSR debería funcionar. Y puedes usar eso para publicar en un JSR. Y eso es todo, realmente. Puedes publicar en JSR y eso es todo.

Y también puedes descargar paquetes con él. Porque con NPM actualmente no soportando completamente JSR de forma predeterminada, estamos haciendo algunos trucos usando el archivo .npmrc, en el cual puedes especificar un registro. Esto es lo que usualmente hacen las empresas en situaciones empresariales. Y básicamente estamos usando esa funcionalidad para apuntar al registro de JSR como un registro alternativo a NPM.

Perfecto. ¿Puede JSR permitirte ver solo descargas de producción con solo servidores minificados de paquetes? No estoy seguro de entender completamente lo que se está preguntando aquí. Quiero decir, solo descargas de producción. Quiero decir, si publicas paquetes, es semi-compatible. Así que si haces pre-lanzamientos, entonces puedes publicar eso. Quiero decir, lo que sea que quieras publicar, puedes publicarlo. No hay imposiciones específicas sobre lo que se está publicando, si está listo para producción o no. Eso realmente depende del mantenedor del paquete y los autores. Y puedes subir cosas minificadas si quieres subir cosas minificadas. No lo recomendamos, pero puedes hacerlo. Entendido.

¿Crees que la gente prefiere nuevas características sobre sostenibilidad? ¿Hiciste alguna investigación sobre esto? ¿En qué sentido sostenibilidad en este escenario? Estoy tratando de pensar. Quiero decir, JSR no es caro de operar, pongámoslo así. Es relativamente sostenible para nosotros actualmente. Tiene costos de gastos relativamente bajos, especialmente porque NPM es relativamente antiguo y tiene un Es más como que NPM tiene muchas capas y se ha construido con el tiempo. Así que tiene mucho desgaste y no está optimizado en algunos aspectos. Mientras que JSR es completamente nuevo, pensamos en estos problemas que NPM tuvo que resolver a lo largo de los años como elementos clave que teníamos que abordar directamente. Así que no tenemos tantos problemas con eso. Pero también, somos mucho más pequeños que NPM, por lo que no tenemos tanto tráfico. Así que sí. Al menos puedes arreglar eso y luego comenzar a hacer más características con seguridad.