El tema es, este comando, npm run, seguro que lo habéis hecho un montón de veces.
npm run, npm run, yo lo hago casi todos los días, constantemente.
Si no es npm run, pnpm run, jan run, lo que sea, siempre lo estamos utilizando, ¿vale?
Y si te digo que dentro de poco no lo vas a utilizar más.
No lo vas a usar más. Se acabó. Fini.
No vas a utilizar más npm run, pnpm run, jan dep, lo que sea.
No lo vas a utilizar más.
Y no lo vas a utilizar más por dos motivos.
Uno, porque no lo vas a necesitar.
Y dos, porque además va a ser mucho más rápido.
¿Y cómo va a ser más rápido esto?
Va a ser mucho más rápido porque, oh sorpresa amigos, y esto es spoiler, lo vais a ver después, más adelante lo vais a ver en todos los sitios,
pero aquí lo habéis visto en el primer sitio.
En el primer sitio.
Y es que Note lo va a añadir de forma nativa.
Lo va a añadir de forma nativa.
Es verdad que hace tiempo que ya la PR la mergearon, el 22 de marzo,
pero en Note 22 ya no necesitaréis utilizar el administrador de paquetes para ejecutar scripts del package.json.
Vais a hacer directamente Note Run.
¿Veis? Note Run.
Y aquí vais a poner lo siguiente.
Y esto además va a tener mejoras de rendimiento.
Por ejemplo, aquí tenéis la diferencia de utilizar NPM Run, que tarda 185 milisegundos, a utilizar Note Run, que fijaos, 30 milisegundos.
Mucho más rápido, mucho más rápido.
Y esto, ¿por qué lo hacen?
Lo hacen por dos motivos, yo creo.
Uno, ya sabéis que Ban, sí que podéis hacer Ban Run, ¿vale?
Podéis hacer Ban Run Depth.
Esto funciona.
Y fijaos que, fijaos en una cosa que parece una tontería, ¿eh?
Pero si yo pongo NPM Run Depth, fijaos cuánto tiempo tarda en aparecer algo debajo, ¿vale?
Son milisegundos, pero fijaos cuando le dé Enter cuánto tiempo tarda, ¿vale?
No tarda mucho, no tarda mucho, pero fijaos que un poquito, un poquito.
A lo mejor son 100, 150 milisegundos.
Pero Ban Run Depth es inmediato.
Son 0 milisegundos, 0 milisegundos.
Pues esto va a ser un poco la misma idea de Note.
Note lo va a querer aquí tener para mejorar todo el tema de ese delay.
Y puede ser que mucha gente piense, bueno, pero yo por 150 milisegundos o 200 milisegundos parece una tontería.
No es tan tontería.
Porque tú, cuando estás en un entorno de desarrollo, puedes pensar que es muy poco.
Pero resulta que cuando tú estás desplegando a producción un proyecto muy grande,
seguro que te ha pasado que a lo mejor tienes un monorepo, monorepositorio, multipaquete,
y haces muchos NPM Run Test, NPM Run, lo que sea, NPM Install, lo que sea, ¿no?
Pues lo que pasa es que esa latencia la tienes que ir sumando para cada uno de los paquetes.
Pues si 150 milisegundos es por cada paquete y tienes 150 paquetes,
pues 150 por 150 son 222 milisegundos, más o menos.
O sea que serían 22 segundos que te podrías estar ahorrando de tiempo.
Que parece poco, pero eso en todos los proyectos es un montón.
Así que son estos detallitos.
Dentro de poco ya no vais a hacer NPM Run, PNP+, Run ni ADA.
Vais a hacer Note, Run y punto.
Y lo vais a tener mucho mejor.
¿En qué se diferencia de NPX?
Pues lo mismo, NPX será parte del administrador de paquetes
y Node Run va a ser directamente del entorno de ejecución.
Y ya está.
Nos damos cuenta que ves la pantalla.
¿Midu, nos damos cuenta que ves la pantalla?
¿Qué quieres decir con eso?
¿Que ves la pantalla?
Claro que estoy viendo la pantalla, pero se lo estoy explicando de la pantalla.
Si aquí tengo vuestro...
Mira, aquí, aquí, viendo aquí, tengo tu chat.
¿Ves?
Si tienes 150 paquetes toca revisar ese proyecto.
Os narrator, no sé si no has...
Yo creo que tú no has programado...
No has trabajado en un proyecto mediano.
Mediano.
O sea, ¿tú cuántos componentes te crees que tiene Meta, por ejemplo?
Es que a veces hace unos comentarios que me sorprende.
O sea, Meta tiene que tener miles de componentes.
Miles de componentes.
Y ya sabemos, ya sabemos que...
Mira, ¿cuántos componentes tiene Meta?
Mira cuántos componentes tiene Meta.
100.000 componentes.
¿No crees que puede tener 150 paquetes Meta?
Tieniendo 100.000 componentes de React.
Pues imagínate que sí.
Ya te digo que no es tan difícil 150 paquetes.
Porque entre paquetes visuales que pueden ser componentes de UI que puedas reutilizar en diferentes sitios.
Piensa en Airbnb.
Todos los componentes visuales que puede tener.
Luego tener un montón de herramientas que pueden ser de análisis, de tracking, de observabilidad, de lógica de negocio, de validación de datos y tal.
No es tan difícil.
150 paquetes no es tanto.
Ya te digo yo, para un proyecto mediano-grande no es tanto.
No te cuesta tanto poco a poco.
Lo mismo que el Hello World de Netflix.
Ahí lo tienes.
¿Cuántos paquetes tienes en la web de la velada?
Pero la web de la velada...
Yo diría que la web de la velada es un proyecto pequeño.
Es un proyecto pequeño.
Cuando hablamos de un proyecto grande, por ejemplo, Airbnb.
Airbnb.
Y sin ir más lejos, si lo miramos fríamente...
Joder, qué zoom tengo en Airbnb.
La madre que me parió.
No sé si Airbnb tiene el...
Airbnb Style Guide...
Style Components.
No sé si tiene los componentes de UI.
Y ahí veréis que ya solo hay componentes de UI.
Esos son paquetes.
Porque los tienen que tener separados justamente para poder reutilizarlos en muchos sitios.
Pero esos son los componentes visuales sin ningún tipo de lógica.
O sea, imaginaos luego la de componentes que pueden tener...
No sé si aparecerá por aquí...
Mira, Components.
Aquí tenemos los componentes.
Y estos son los únicos componentes que deben tener aquí.
Todo esto...
Todo esto...
Y, bueno, es que deben tener millones más.
3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15.
Y estos son los componentes visuales más básicos y que tienen aquí.
O sea...
Y ya tienes...
Ya te comes 15.
Pues imagínate.
Son los más básicos.
Te comes 15.
Pues no tienen que tener proyectos ni nada.
O sea, es que me imagino que tienen que tener una burrada.
En tu curso de React lo estoy empezando...
Empiezas con MPM.
¿Puedo usar en vez PNPM?
Claro que sí.
Lo puedes hacer sin ningún tipo de problema.
Me acordé que no me había resuscrito.
Gracias, Alex, por resuscribirte.
Gracias, gracias.