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í.
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
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.
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?
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.
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)
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
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
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
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.
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".
Gran video acabo de entender un fallo que tenía en mi código!
Excelente hermano , muchas gracias por compartir esta valiosa información. Saludos desde Venezuela.
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! 🤗
ahhhhhhh me salvaste loco!!! Esto con pnpm me soluciono la vida.
Genial, Tony! :D
Muy buena explicación, bastante útil.
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
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 ❤
Excelente video, eres un pro!!
Gracias!
Quisiera que youtuve tuviera otro boton de like solo para midudev, Gracias hombre... todo un genio.
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.
Eres un máster, increíble!
Llegue temprano. Gracias Midu
Genial Midu grande
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í.
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
¿Que configuración-tema tienes en tu iTerm?
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
saludos que buen video, para aprender la utilidad de esos archivos gracias
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.
y habra alguna forma de fijar todas las versiones de un package.json que se encuentra con todas las dependencias con los valores "latest" ?
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
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.
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)
Alguien podría explicarme que sería "aplanar una dependencia"? Gracias de antemano
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
Yo lo conocia como sombrerito chino
Ja, ja, ja, qué bueno.
Geniooooo.
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
Liberty Liberty Liberty
Muchas gracias
lo maximo
Entonces si necesito actualizar una dependencia es mejor quitar siempre el caret 😮
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.
yarn 3, pnpm?
Les pasa lo mismo
Gracias, no sabía esto, npm es una mierda... 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
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.
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.
No entendi nada xd
Se escucha mal
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í 😎