Más que el salseo que ya lo tenía leído me gusto mucho como explicaste el funcionamiento de npm a la hora de aplanar el instalado de dependencias. No sabía muchas de las cosas que explicaste, a demás el consejo de la extensión de VSC Version Lens me parece genial para los que nos gusta cotillear por git y ver un poco de que van todas esas dependencias que como junior solemos dejar que hagan nuestro trabajo sin saber bien de que van. Saludos y gracias Midu
Es impresionante! Cada vez que me sale un video de este buen hombre, aprendo de todo. El nuevo refrán: "No veras un video de midu, sin aprender algo nuevo".
+1 Para eso esta package-lock para fijar tu version exacta como dices. ademas es mala practica fijar librerias a ciertas versiones especificas, xq no dejas rango x si luego quieres instalar otra libreria y no tiene soporte para la version que usas. Igualmente te queremos midudev ❤
Corrígeme si me equivoco pero, cuando una dependencia entra en conflicto con otra por la versión de una dependencia en común, npm lo que hace es que crea una directorio node-modules dentro de cada dependencia para evitar ese conflicto de versiones. no toma cualquier arbitrariamente porque eso no es correcto.
Sí, aunque en el caso de las peerDependencies, sí hay algún conflicto y fuerzas, creo que usará la versión que tu hayas instalado aunque no sea la correcta para la dependencia que la necesita. Por eso antes de instalar pkgs hay que revisar siempre el package.json y ver todo ese tipo de detalles.
Midu cuando trabajas con Angular y lanzas ng new el crea todas las dependencias de su core con carets... yo creería que si son manteiners empresariales tipo Google podemos dejarlos así.
Recientemente tuve un problema en un proyecto, concretamente con el paquete ngx-mask y sospecho que tiene que ver con este problema que relatas. A mí equipo de trabajo, de un momento a otro a algunos dejó de funcionar ese paquete, a algunos si les funcionaban las máscaras y a otros no. Al final, por el tiempo, decidimos mudarnos a otro paquete.
Pero el package-lock.json no soluciona ese problema? Es decir si yo tengo package-lock.json en el repo y hago un mpi despues de que la nueva version con codigo malicioso dea publica, no pasaria nada por q la version esta "lockeada" en el package-lock.json. solo tendría problemas si borro el package-lock.json y hago un install
es para todos? por que se puede usar el * para que sea el ultimo dijo unicamente el que cambie, se supone que en el versionamiento, ese digito corresponde a fixes no? ( obviamente se que se lo pueden pasar por donde quieran, pero se parte de la buena fé siempre )
Bueno, trataré de resumirlo. Midu, cuando coloco: brew install node... al final de la descarga me aparece este mensaje: Running `brew cleanup node`... Disable this behavior by setting HOMEBREW_NO_INSTALL_CLEANUP. Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`). Después coloco: brew update... y me muestra: Already up-to-date. Eso quiere decir que está instalado y además en la ultima versión. Después: node -v ... y me dice 17.4.0 Después npm -v y me dice 8.3.1 Después de allí no he querido colocar otro comando más porque no sé si instaló correctamente por ese ultimo mensaje que me muestra la terminal al instalar node con brew, qué debo hacer? TODO ESTO EN LA TERMINAL DE MACOS.
Que opinas de usar ~version “Approximately equivalent to version” ?, el problema podria seguir pasando pero seria mucho menor si ponemos que solo actualize patches sin modificar Mayor y minor versions.
Creo que si el proyecto tiene una sólida base de tests igual se podría usar el caret, si al actualizar las dependencias hace que explote algún test, hasta allí llega la historia de esa actualización, útil para casos como dependbot en github con CI/CD ¿qué opinan?
Me pasó que desplegué un proyecto que funcionaba y empezó a sacar errores, resulta que un paquete estaba actualizado y una dependencia estaba generando un problema. O sea, no uses carets.
No entendí muy bien, que pasa si instalo una dependencia que a su vez tiene otras dependencias, a pesar de que yo use la versión fija de esa dependencia(sin el caret), las dependencias de la dependencia pueden ser variables (con el caret)
Esto va a sonar muy noob pero en el tema de dependencias y como gestionarlas soy totalmente nuevo,. En primer lugar, como de importantes son las vulnerabilidades de las que te avisa expo-cli cuando instalas un nuevo paquete? A caso es posible conseguir el 0 vulnerability? xd
Eso ya depende de los desarrolladores del cli, por ejemplo, para web con nextjs, hasta ahorita me da 0 vulnerabilidades. Con create react app me daba como 7 vulnerabilidades graves. Y con Vite me daba warnings. En general no afectan mucho, no te das cuenta. Si intentas actualizar a la fuerza vas a romper el proyecto, así que mejor espera futuras actualizaciones de expo
joe ni siquiera se puede confiar en los updates :c jsjsj/ buen dato para los nuevos que ingresan yo desconocia, lo tendre en mente a futuros proyectos , me perdi un pco lo volvere a ver
Muy bueno el vídeo pero hay algo que no entiendo. Según creo, el package-lock.json existe para evitar el problema del ^, de modo que en dicho fichero tenemos las versiones exactas usadas y aunque hagamos npm install, siempre que no hayamos modificado el package.json, se nos instalaran las mismas versiones que ya teníamos, y no se actualizará ninguna. No sé si estoy equivocado, pero pensaba que funcionaba de esta forma.
x2, segun yo esa era la gracia del package-lock. Mantener la integridad de las dependencias que instalaste. Esperemos que @midu nos aclare esto o ver que tiene por decir
Lo explico al principio del vídeo. El package-lock es para las dependencias de tu proyecto. Si tu proyecto es una dependencia de otro proyecto, no puedes controlar que tenga un package-lock. Eso es lo que pasó con paquetes como karma.
Ahh, cierto, se me había pasado ese detalle. Pues aclarado queda, muchas gracias, tu canal es una maravilla y tus explicaciones siempre son muy útiles. Saludos.
oye, pero el problema que mostraste es por *no* usar el caret en tu proyecto, es decir, si tu proyecto y todas la dependencias usarán el caret, siempre tendrías la ultima version
Más que el salseo que ya lo tenía leído me gusto mucho como explicaste el funcionamiento de npm a la hora de aplanar el instalado de dependencias. No sabía muchas de las cosas que explicaste, a demás el consejo de la extensión de VSC Version Lens me parece genial para los que nos gusta cotillear por git y ver un poco de que van todas esas dependencias que como junior solemos dejar que hagan nuestro trabajo sin saber bien de que van. Saludos y gracias Midu
Es impresionante! Cada vez que me sale un video de este buen hombre, aprendo de todo. El nuevo refrán: "No veras un video de midu, sin aprender algo nuevo".
Excelente hermano , muchas gracias por compartir esta valiosa información. Saludos desde Venezuela.
Gran video acabo de entender un fallo que tenía en mi código!
Muy bueno el video. Siempre información muy útil y excelente la explicación. Gracias. Saludos.
wow no sabia eso y creo que el 90% de los desarrolladores confian ciegamente en el npm, gracias por el video.
Gracias a ti, Felipe! 🤗
Quisiera que youtuve tuviera otro boton de like solo para midudev, Gracias hombre... todo un genio.
Excelente video, eres un pro!!
Gracias!
ahhhhhhh me salvaste loco!!! Esto con pnpm me soluciono la vida.
Genial, Tony! :D
Muy buena explicación, bastante útil.
Usar "npm ci" soluciona esos problemas y además es mucho más rápido, porque solo busca es instala las versiones exactas del package-lock
+1 Para eso esta package-lock para fijar tu version exacta como dices. ademas es mala practica fijar librerias a ciertas versiones especificas, xq no dejas rango x si luego quieres instalar otra libreria y no tiene soporte para la version que usas. Igualmente te queremos midudev ❤
Ese plugin también lo uso, también se puede con npm outdated, y tener global el npm check updates, darle ncu -u y después un npm install
Corrígeme si me equivoco pero, cuando una dependencia entra en conflicto con otra por la versión de una dependencia en común, npm lo que hace es que crea una directorio node-modules dentro de cada dependencia para evitar ese conflicto de versiones. no toma cualquier arbitrariamente porque eso no es correcto.
Sí, aunque en el caso de las peerDependencies, sí hay algún conflicto y fuerzas, creo que usará la versión que tu hayas instalado aunque no sea la correcta para la dependencia que la necesita. Por eso antes de instalar pkgs hay que revisar siempre el package.json y ver todo ese tipo de detalles.
Midu cuando trabajas con Angular y lanzas ng new el crea todas las dependencias de su core con carets... yo creería que si son manteiners empresariales tipo Google podemos dejarlos así.
Eres un máster, increíble!
Recientemente tuve un problema en un proyecto, concretamente con el paquete ngx-mask y sospecho que tiene que ver con este problema que relatas. A mí equipo de trabajo, de un momento a otro a algunos dejó de funcionar ese paquete, a algunos si les funcionaban las máscaras y a otros no. Al final, por el tiempo, decidimos mudarnos a otro paquete.
¿Que configuración-tema tienes en tu iTerm?
Genial Midu grande
Pero el package-lock.json no soluciona ese problema?
Es decir si yo tengo package-lock.json en el repo y hago un mpi despues de que la nueva version con codigo malicioso dea publica, no pasaria nada por q la version esta "lockeada" en el package-lock.json. solo tendría problemas si borro el package-lock.json y hago un install
es para todos? por que se puede usar el * para que sea el ultimo dijo unicamente el que cambie, se supone que en el versionamiento, ese digito corresponde a fixes no? ( obviamente se que se lo pueden pasar por donde quieran, pero se parte de la buena fé siempre )
Bueno, trataré de resumirlo. Midu, cuando coloco: brew install node... al final de la descarga me aparece este mensaje: Running `brew cleanup node`...
Disable this behavior by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
Después coloco: brew update... y me muestra: Already up-to-date. Eso quiere decir que está instalado y además en la ultima versión.
Después: node -v ... y me dice 17.4.0
Después npm -v y me dice 8.3.1
Después de allí no he querido colocar otro comando más porque no sé si instaló correctamente por ese ultimo mensaje que me muestra la terminal al instalar node con brew, qué debo hacer?
TODO ESTO EN LA TERMINAL DE MACOS.
Que opinas de usar ~version “Approximately equivalent to version” ?, el problema podria seguir pasando pero seria mucho menor si ponemos que solo actualize patches sin modificar Mayor y minor versions.
y habra alguna forma de fijar todas las versiones de un package.json que se encuentra con todas las dependencias con los valores "latest" ?
saludos que buen video, para aprender la utilidad de esos archivos gracias
Creo que si el proyecto tiene una sólida base de tests igual se podría usar el caret, si al actualizar las dependencias hace que explote algún test, hasta allí llega la historia de esa actualización, útil para casos como dependbot en github con CI/CD ¿qué opinan?
con renovate bot puedes checar esas actualizaciones de paquetes y saber si se rompe, igual que con las herramientas que mencionaste
Me pasó que desplegué un proyecto que funcionaba y empezó a sacar errores, resulta que un paquete estaba actualizado y una dependencia estaba generando un problema. O sea, no uses carets.
No puede ser posible, un midu máster que nos explica todo como un crack, y a la vez un midu guapo que conquistaria Roma con una mirada 7u7
No entendí muy bien, que pasa si instalo una dependencia que a su vez tiene otras dependencias, a pesar de que yo use la versión fija de esa dependencia(sin el caret), las dependencias de la dependencia pueden ser variables (con el caret)
Llegue temprano. Gracias Midu
Alguien podría explicarme que sería "aplanar una dependencia"? Gracias de antemano
Esto va a sonar muy noob pero en el tema de dependencias y como gestionarlas soy totalmente nuevo,. En primer lugar, como de importantes son las vulnerabilidades de las que te avisa expo-cli cuando instalas un nuevo paquete? A caso es posible conseguir el 0 vulnerability? xd
Eso ya depende de los desarrolladores del cli, por ejemplo, para web con nextjs, hasta ahorita me da 0 vulnerabilidades. Con create react app me daba como 7 vulnerabilidades graves. Y con Vite me daba warnings. En general no afectan mucho, no te das cuenta. Si intentas actualizar a la fuerza vas a romper el proyecto, así que mejor espera futuras actualizaciones de expo
joe ni siquiera se puede confiar en los updates :c jsjsj/ buen dato para los nuevos que ingresan yo desconocia, lo tendre en mente a futuros proyectos , me perdi un pco lo volvere a ver
Muchas gracias
Muy bueno el vídeo pero hay algo que no entiendo. Según creo, el package-lock.json existe para evitar el problema del ^, de modo que en dicho fichero tenemos las versiones exactas usadas y aunque hagamos npm install, siempre que no hayamos modificado el package.json, se nos instalaran las mismas versiones que ya teníamos, y no se actualizará ninguna. No sé si estoy equivocado, pero pensaba que funcionaba de esta forma.
x2, segun yo esa era la gracia del package-lock. Mantener la integridad de las dependencias que instalaste. Esperemos que @midu nos aclare esto o ver que tiene por decir
Lo explico al principio del vídeo. El package-lock es para las dependencias de tu proyecto. Si tu proyecto es una dependencia de otro proyecto, no puedes controlar que tenga un package-lock. Eso es lo que pasó con paquetes como karma.
Ahh, cierto, se me había pasado ese detalle. Pues aclarado queda, muchas gracias, tu canal es una maravilla y tus explicaciones siempre son muy útiles. Saludos.
Yo lo conocia como sombrerito chino
Ja, ja, ja, qué bueno.
curioso. eso pasaría en Deno?
Depende. Si usas una versión fijada, pues no. Pero si usas la URL a saco en el import, pues pasaría lo mismo.
Entonces si necesito actualizar una dependencia es mejor quitar siempre el caret 😮
Geniooooo.
lo maximo
oye, pero el problema que mostraste es por *no* usar el caret en tu proyecto, es decir, si tu proyecto y todas la dependencias usarán el caret, siempre tendrías la ultima version
Justamente al usar caret te instalá la última versión de patch y minor, lo que a veces puede romper tu proyecto. Es lo que explica el vídeo.
yarn 3, pnpm?
Les pasa lo mismo
Gracias, no sabía esto, npm es una mierda... Saludos
Liberty Liberty Liberty
Se escucha mal
No entendi nada xd
ni siquiera sé que es un package por eso buscaba algo info pero sigo sin e n t e n d e r
no entendí 😎