Ha pasado esto, entonces os voy a explicar, os voy a explicar cómo solucionarlo, por qué, os he explicado muchas veces por qué quito los carrots y mucha gente muchas veces me dice, ¿qué quiero los carrots?
Muchas veces yo quito los carrots, en todos mis proyectos me lo habéis visto mil millones de veces, que quito los carrots, ahora os explico qué son los carrots, qué significa, cómo lo puedes hacer, cómo puedes evitar este problema que ha pasado esta mañana en un montón de proyectos y tal.
En sí, ¿cuál es el salseo? Resumen breve, no necesito detalle. El salseo es que un mantenedor, maintainer de diferentes proyectos de código abierto importantes en la comunidad, ha decidido de golpe publicar dos versiones maliciosas, porque rompen la funcionalidad de esos paquetes,
y no sabemos exactamente sus motivaciones o si hay más de una, pero lo que sí sabemos es que ha sacudido bastante a la comunidad de código abierto
y además nos ha hecho preguntarnos si realmente nuestro código es nuestro o no lo es. Ese sería un poquito el resumen.
Hay una manera de evitar que se autoricen los paquetes automáticamente desde el mismo comando de instalación de MPM, pero no recuerdo cómo era, te recomiendo investigarlo.
No, a ver, lo que podéis hacer, lo que pasa es que son dos cosas distintas, ¿vale? Por un lado estaría el tema del package log.
El package log, lo que, ¿qué demonios es package log? Bueno, el package log lo que os va a servir es justamente para que si tenéis y hacéis un MPM install de ese,
o sea, de ese proyecto, se va a asegurar que las dependencias que instaláis sean exactamente las mismas.
O sea, el package log está bien para ponerlo en un proyecto de GitHub, ¿no? Y que cuando se descargue el package log, pues tengas exactamente las mismas dependencias.
Pero esto no soluciona el problema que ha tenido esta persona, porque el package log es para el proyecto, no para la dependencia como paquete, ¿vale?
O sea, el paquete, al final eso lo tenemos en el package JSON, lo cual es diferente, así que importante, ¿vale?
¿Qué es lo que pasa? Vale, amigos, vamos a verlo, ¿vale? Cuando vosotros empezáis un proyecto, vámonos aquí a TMP.
Ah, por cierto, tengo aquí, si no, mira, git, no, twitch, a ver, voy a buscar porque creo, mira, colorsloop, tengo aquí la versión colorsloop, note,
mira, tengo aquí la versión, la chunga, tengo la versión chunga, amigos, mira.
Ahí lo tenéis. Lo he quitado rápido porque se pone un loop infinito, ¿eh? Pero, mira, liberty, liberty, liberty, y esto se pone aquí hasta infinito y ya está.
No, si lo ejecuto, lo dejo, se me empieza a petar aquí el stream. Pero bueno, para que veáis que está aquí.
Le podéis echar un vistazo, mira.
Gracias por el midu salseo.
Gracias a ti.
Nos vemos el siguiente lunes con más salseo.
Capa.
Hombre, espero que no. Espero que no. Espero que no haya salseo todos los días.
Mira, aquí tenéis el paquete de colors y, no sé, mira, American.
Aquí tenéis esto.
América. Bueno, esto lo he caído justamente.
Vale.
El tema. Vamos a crear un nuevo proyecto para que entendáis qué es lo que ha pasado en tantos y tantos proyectos.
De hecho, lo podemos ver fácilmente, ¿eh?
Si yo me voy, por ejemplo, a Karma Runner, vamos a ver aquí el problema.
Aquí en package, ta, ta, ta.
A ver, package, package.
¿Veis que tiene un package lock?
Pero este package lock...
Ay, sí, perdón, ¿eh? Es que, joder.
Es que el Visual Studio Code consume un montón.
A madre que trajo.
Vale.
Aquí tendríamos el package de la dependencia de Karma.
¿Qué significa?
Que cuando hacemos un npm install de Karma, de esta dependencia de Karma, o sea, cuando tú haces un npm install de Karma, Karma tiene sus propias dependencias, ¿vale?
Tiene sus propias dependencias.
Y entonces, cuando hace el npm install, podríamos, o sea, podríamos no, va a instalar todas estas dependencias.
Todas estas dependencias.
Entre las dependencias, mirad que hay aquí, colors, ¿vale?
Pero, ¿qué pasa?
Que tiene un caret.
A este símbolo se le llama caret.
Este caret es el problema.
Es el problema.
Como podemos ver, aquí todas las dependencias que tiene aquí, tiene un caret.
Y el caret lo que va a hacer es, no solo instalar la versión 1.19.0, sino que va a instalar la 1.20.0, 1.21.0.
Bueno, de hecho, para que estemos seguros de esto, lo que podéis hacer es package.json.version.playground.
Creo que hay...
Playground.
A ver si ahora me acuerdo.
Package.version.playground.
A ver si en el json.
No.
Npm.
No.
Ostras.
No me puedo creer que ahora no lo voy a encontrar.
Hay una...
Type checker.
Version.
Checker.
Npm.
No.
Ah, no lo voy a encontrar.
A ver si alguien se lo sabe.
Hay un...
Hay una...
Hay un proyecto que está bastante bien.
Que está bastante chulo.
Ah, mira, aquí está.
Si es que es oficial de NpmGS.
Este, vale.
Este, mira.
Por ejemplo, aquí tú pones un paquete, ¿no?
Y aquí puedes poner cuál sería el rango.
El rango es lo que tenemos en el package.json.
Por ejemplo, aquí esto sería el rango.
Vale.
Caret, 4, no sé qué, no sé cuánto.
Hay diferentes rangos que puedes poner, pero por defecto, justamente, se utiliza el del caret.
¿Vale?
Pues aquí podemos ver que si tú pones este rango de caret 4.2.6, lo que le quieres decir, en realidad, es que vas a poder utilizar cualquiera que sea por encima sin cambiar la major.
¿Vale?
O sea, este se mantendría, pero va a ser 4.3.0, 4.2.7, 4.80.92.
Esos van a funcionar.
De hecho, lo puedes ver aquí.
Aquí en verde tendrías los paquetes que van a encajar con esta versión.
Y podemos ver que la 4.3.0, la 4.4, ¿vale?
Aquí lo podemos ver.
Si yo pongo aquí la 1.1.10, 1.2.6, pues estas.
Pero la 2.0 no lo acepta.
¿Vale?
Esto, ¿qué significa?
Que si yo pongo aquí 4.0.0, que es lo que suele ocurrir, ¿no?
Pues automáticamente, cuando tú haces un MPM install, lo que va a pasar es que va a intentar buscar la versión que encaje.
Si la va a buscar a internet, va a ponerte la última.
Pero hay veces, hay veces que tienes una subdependencia.
Por ejemplo, imagínate que Loadash lo utilizas en un proyecto muy grande y hay una subdependencia que tiene la 4.8.2.
Pues lo que va a hacer, que esto también muy poca gente lo sabe, es utilizar la 4.8.2.
No te va a instalar la última.
No, no, no.
Te va a instalar la que ya se encuentre en tu proyecto.
Si en tu proyecto hay una subdependencia que es Loadash 4.14.0, cuando veas esto, va a instalar 4.14.0.
¿Y os recomiendas en nuestros proyectos sin el caret?
Sí, siempre.
Siempre.
Os recomiendo siempre que lo utilicéis sin caret.
Y ahora os voy a explicar cómo, aunque si me seguís, pues lo habréis visto 80 veces, ¿vale?
Pero mira, node project.
Y hacemos un npm init-y.
¿Vale?
Esto nos inicializa el proyecto.
Vamos a hacer un npm install de colors, justamente, para hacer la gracia.
npm install colors, ¿vale?
Cuando haces un npm install colors, te dice cuántos paquetes han añadido.
Entre 100 milisegundos, ¿vale?
Hago un cat package.json y vamos a ver el contenido del archivo.
Y podemos ver que las dependencias me han instalado colors con el caret, ¿vale?
Caret 1.4.0.
Esto significa que la última que ha instalado es la 1.4.0.
¡Ay!
Al final, lo he instalado directamente aquí.
No he entrado en el proyecto.
Pero bueno, no pasa nada.
Al final, como está en package, en el temp, en el tmp, no pasa nada.
Vale.
Lo importante es, en las dependencias tenemos 1.4.0.
Si la semana que viene sale la 1.5.0, lo que va a pasar es que va a instalar,
cuando yo haga un npm install, la instalará.
Hay que diferenciar entre el package.log y el package.json,
porque el package.log me va a mantener las dependencias seguro,
cuando yo me descargue este paquete, pero para trabajar en él,
no como dependencia.
Si lo hago como dependencia, lo que va a ocurrir es que me va a instalar
el colors, la 1.5.0, lo que sea.
Para hacer esto correctamente, o al menos no correctamente,
como yo lo haría, ¿vale?
Sería hacer un npm install, colors, y yo le pongo el menos e,
que lo que significa es que va a guardar la versión exacta.
Si le das, lo que vas a ver en el package.json es que no utiliza el caret, ¿vale?
Entonces, el tema es que no deberíais utilizar nunca el caret.
Nunca deberíais utilizar el caret.
Esta es mi recomendación.
Es una cosa que siempre digo.
Hay mucha gente que me dice, ah, no sé qué, no sé cuánto.
Y, de hecho, muchos proyectos como este, estos proyectos,
ves que tiene caret, caret, caret, caret, caret, caret, caret.
¿Por qué utilizan el caret?
¿Por qué utilizan el caret?
Hay dos motivos, ¿vale?
El primero, porque así tienes que mantener menos esas dependencias
y se van actualizando solas.
Pero por un segundo motivo, es también lo que os comentaba.
También lo que puede ocurrir es que tengas un proyecto
que ya utilice esa dependencia.
Vamos a ver un ejemplo, ¿vale?
Claro, bug fixing puede ser una, ¿no?
Para recuperar automáticamente los errores que se arreglan
en las dependencias.
Pero también lo hacen, justamente, y vamos a ver cómo lo podemos ver.
Mira, aquí tenemos loadash, ¿vale?
Vamos a ver los proyectos que utilizan loadash.
A ver si encontramos un proyecto que utilice loadash
que sea chiquitito.
A ver, un proyecto que utilice loadash que sea pequeñito.
Use by validator.
A ver este.
Es que esto...
A ver, estoy pensando cómo os puedo enseñar este ejemplo.
Porque este ejemplo es bastante interesante.
Es que Karma es bastante grande.
Si instalo Karma...
A ver, Karma.
Venga, va, vamos a intentar instalar Karma
a ver qué pasa, ¿vale?
Venga, y os enseño esto.
Imaginad que yo tengo aquí en code...
Vamos a ir a Karma.
Ah, pero Karma está utilizando una versión...
A ver, a ver.
GitHub Karma.
Es que con esto lo vais a ver clarísimo.
El tema este.
Y además vais a entender algo que muy poca gente entiende
y es bastante importante.
Porque tiene un montón de implicaciones.
Colors...
Claro, es que ya tiene la 1.4.0.
Lowdash.
Sourcemap.
Bueno, si no, puedo buscar un proyecto de suy components.
O jQuery.
A ver, yo que sé.
O React.
A ver, un momento.
Vamos a poner React.
Facebook.
Qué fuerte que he puesto React y no me sale el primer repositorio
como el de React.
O sea, el buscador de GitHub, menos mal que lo van a cambiar, ¿eh?
Porque no veas.
No veas.
No veas.
GitHub React Repositorio.
Porque mira, el de Google va mejor.
Va mejor que el de...
Vale.
Vamos a ver aquí el Package.json.
Estos son dependencias de desarrollo.
Es que nada, no tiene dependencias normales.
Joder.
Ah, vale.
Están aquí.
React DOM.
Package.json.
Vale.
Dependencias.
Object Assign.
Vale.
Vamos a ver.
Object Assign.
¿En qué versión van?
Joder.
Justamente la última.
Casi no lo vais a ver.
Lose Mbify.
1, 4, 0.
Vale, vale.
Mira, aquí tenemos un buen ejemplo.
Aquí tenemos un buen ejemplo.
Venga, vamos a ir al proyecto de Node Project este que hemos hecho aquí.
Hago un npm init.
¿Vale?
Vale.
Entonces, imaginad que yo tengo este proyecto de Node y digo,
voy a instalar Lose Mbify, ¿no?
Quiero instalar Lose Mbify y quiero instalar la versión
1 punto lo que sea.
npm install y digo Lose Mbify
y lo hago con menos C, ¿vale?
Hago ahora un npm ls y puedo ver que me ha instalado la 1.4.0, ¿vale?
La 1.4.0.
Entonces, la 1.4.0.
Si yo ahora instalo justamente React DOM,
lo que va a ocurrir aquí es que va a utilizar la 1.4.0.
O sea, yo hago npm install, React DOM.
Si hago un npm ls,
como puedes ver, me ha instalado Lose Mbify, la 1.4.0, React DOM.
Vale.
Vamos a mirar React DOM.
De hecho, puedes buscar Lose Mbify para ver cuántas veces la ha instalado.
Lo que podemos ver es que siempre ha instalado la 1.4.0, 1.4.0, 1.4.0, 1.4.0.
O sea, solo la ha instalado una vez y la ha deduplicado.
¿Por qué?
Porque aquí lo que estamos diciendo es, vale,
cualquier dependencia que sea mayor de la 1.1.0 ya no funciona.
O sea, la 1.4.0 nos va bien.
¿Qué quiere decir esto?
Esto lo que quiere decir es que si por lo que fuese,
yo tengo aquí la 1.4.0 es la última, ¿no?
Entonces, por eso parece que me ha estado la última.
Si yo pongo esto, ya la pongo la 1.2.0
y elimino todos mis node modules
y hago un npm install.
Si hago un npm ls de Lose Mbify,
lo que vamos a ver es que ha utilizado la 1.2.0 en todo mi proyecto.
En cambio, la última es la Lose Mbify.
¿Por qué está pasando esto?
¿Ves? La última es la 1.4.0.
Pero en cambio, en todo mi proyecto está la 1.2.0.
Y es que lo que está pasando es que cuando en esta dependencia
está habiendo la 1.1.0,
y esto es súper peligroso porque, como ha dicho antes,
L'Olivier, Iván L'Olivier, que ahora no me he acordado del nombre,
era el tema del bug fixing.
Pero no es cierto siempre.
¿Por qué?
Porque si tú tienes esa misma dependencia en tu proyecto
con una versión pineada anterior,
nunca vas a recibir el bug fixing
que se supone que debería llegarte con el caret.
Nunca vas a recibir la latest.
Nunca vas a tener las últimas versiones.
Porque tú en algún otro sitio,
y ni siquiera necesitas que sean tu propio proyecto,
puede ser en otra dependencia hermana.
Imagínate que hay una dependencia
que tiene aquí Lose Mbify 1.2.0
y aquí tienen este caret que dice,
vale, cualquiera por encima de la 1.1.0 me vale.
Lo que va a pasar es que van a utilizar la 1.2.0.
No va a utilizar la última tampoco.
Esto es una cosa que muy poca gente se da cuenta que pasa
en los proyectos de frontend,
que creen que de alguna forma hace alguna magia
que te instala las últimas y tal,
pero no.
Lo que está pasando es que MPM está intentando
hacer las mínimas instalaciones posibles.
De forma que si tú le dices que aquí te sirve cualquiera
que sea la 1.1.0, por encima de la 1.1.0,
sin contar las mellos,
lo que va a hacer es economizar el tiempo,
las instalaciones y todo.
Así que esa es la historia.
Igualmente, para evitar este tipo de problemas,
como hemos visto, que te cuelen un paquete con un fix,
que en realidad no es un fix,
pues no uséis los caret.
Había alguien que me preguntaba,
pero bueno, utilizo los caret al menos para...
¿Las depth dependencies?
Para las depth dependencies suele ser menos grave.
¿Por qué?
Porque las depth dependencies al final,
si por lo que sea revienta,
pues es muy fácil que puedas dar marcha atrás.
A lo mejor como mucho te puede llegar
continuous integration y tal,
pero no es lo mismo.
En cambio, en tus dependencias va a ser mucho más grave.
Así que en las depth dependencies lo podrías dejar,
yo no lo hago, prefiero hacerlo manualmente,
pero no sería tan grave.
Las dependencias, yo al menos lo evito.
Y si hay dos paquetes hijos con versiones exactas,
ahí sí cada uno instala lo que necesita.
Efectivamente, Iván L'Olivier.
En ese caso, en el que tú tengas dos versiones exactas diferentes,
instalaría las dos diferentes.
Y con eso, además, podría pasar...
Podría pasar algo bastante curioso.
Si tú tienes dos versiones del mismo paquete en 50 paquetes diferentes,
te va a instalar ese paquete 49 veces.
Es un poco raro, sé que suena raro,
pero lo que va a pasar...
O sea, te lo puede instalar hasta 49 veces.
¿Qué quiere decir esto?
Pues que aplanar las dependencias solo puede hacer una vez,
porque las deja en la raíz.
Pero una vez que encuentra versiones divergentes,
solo a la aplana una vez.
Por lo tanto, las versiones que no ha aplanado,
las va a estar repitiendo,
instalando en cada node modus que se encuentre de las subdependencias.
Es un temazo bastante interesante.
Y eso puede ser bastante problemático muchas veces,
porque además el aplanamiento no lo hace en PM,
dependiendo de cuál es más importante
o cuál es la que se repite más veces.
Es la primera que encuentra.
Entonces, si a lo mejor la primera que encuentra
es la que menos se repite,
la aplanará esa
y luego instalará 80 veces la otra.
Bueno, 80 o tantas veces como...
Por eso el node modus a veces pesa tanto.
Efectivamente.
Efectivamente.
Bueno, pues esta ha sido la pedazo de historia, ¿vale?
Y por eso os recomiendo un montón que...
Vamos a leer un poco,
porque me parece muy interesante.
La gente se ha vuelto muy loca aquí en Twitter
para seguir un poco con el salseo.
Y con librerías grandes como React,
si queremos actualizar la última versión.
A ver, yo lo tengo en un montón de proyectos.
Lo tengo en un montón de proyectos.
Y al final lo que hacemos es tenerlo a mano.
Es tenerlo a mano.
O sea, lo que hay que hacer es tenerlo,
por ejemplo, yo qué sé,
no sé si aquí tenemos esto...
O puedes utilizar la mayor.
Si lo tienes muy claro,
puedes utilizar la mayor.
Que al final es lo mismo que utilizar la caret.
Pero claro, es que esto son...
Esto al final es diferente.
Porque en este caso es diferente
porque es una herramienta que solo te desarrollo y tal.
Pero para React puedes hacer lo mismo.
O sea, lo pineas...
Y yo, por ejemplo, lo que hago mucho,
utilizo mucho,
es esta extensión de Visual Studio Code
que se llama Version Lens,
que te recomiendo un montón,
en la que aquí te va diciendo,
mira, está fijada a 1.2.0.
Y la latest es la 1.4.0.
Pues tú le das un clic aquí,
pling,
y te la cambia y ya está.
Entonces, ¿qué haces?
Pues imagínate que tú tienes la 1.0.1 aquí, ¿vale?
Pues aquí te dice,
mira, tienes fijada aquí
y aquí tienes esta, ¿vale?
Pues le das y te la actualiza.
Haces una instalación de las dependencias,
ejecutas los test y ya está.
Y mejor que mejor.
Yo creo que es una forma bastante buena
de tener cuidado con este tipo de cosas.
Justamente esto te hubiera evitado
el problema que has tenido.
O sea, que has tenido tú, no.
Me refiero a que ha tenido un montón de proyectos.
Y luego, tiene todo el sentido del mundo
evitar que las dependencias estén como locas por ahí.
Así que...
Hola, Amidu.
¿Podrías hacer en un futuro
explicando esto en más profundidad?
¿Más profundidad todavía?
Joder, por si creo que lo he explicado
con bastante profundidad.
Guayco, sí.
Yo creo que lo recomendable
es actualizar a mano el package.json.
Actualizar a saco el package.json.
Mira, yo, por ejemplo, lo que hago
para actualizar mis dependencias
es LoseMbify, ¿vale?
Por ejemplo, imagínate que yo estoy aquí
en la 1.3.0
y veo que está la 1.4.0.
Yo lo que hago, justamente,
fíjate que cuando haces hover,
ves que he puesto hover
y ya te aparece aquí
una descripción del proyecto y todo.
Entonces, ya le doy aquí
y lo que hago es buscar el changelog.
Que a veces no hay changelog.
Como es este el caso.
Ves que no hay un changelog.
Bueno, pues te vas a releases
y aquí en releases tampoco tiene.
Bueno, pues entonces,
en el caso que ocurra esto,
que tiene bastantes bichos,
porque entonces el paquete
es difícil de mantener, de ver,
pues entonces voy a los commits.
Y voy a los commits
y me pongo a ver
cuáles son los cambios que han habido.
Hay otros paquetes que, por suerte,
sí que tienen esto mejor.
Por ejemplo,
¿cuál es el alguno que he estado mirando?
Pues Slint.
Por ejemplo, he estado mirando antes Slint
porque estaba actualizándolo.
He ido a Slint
y he buscado el changelog.
¿Ves?
Y el changelog además te van diciendo,
vale, en la 8.6.
Entonces te pones a mirar.
Vale, core, core.
Dice, ha actualizado esto,
ha actualizado esto,
docs, vale, sin importar, pa, pa, pa.
Luego, si es una mayor,
lo que te pones a mirar aquí
normalmente son los breaking
y aquí lo que suelo hacer
es buscar breaking
para que no se me escape.
Breaking, disallow, reserve.
Breaking, remove.
Me pongo a mirar.
Hay veces,
¿ves?
Breaking, breaking.
Y yo me los leo todos.
Me leo todos los breaking,
me los miro todos.
Luego hay veces
que también, por suerte,
pues tienen los,
¿cómo serían?
Las migration, ¿vale?
Que te dicen
cómo migrar de una versión a otra.
Y eso está bastante bien,
¿vale?
Eso está bastante bien.
Y si no,
en releases
lo tienen bastante bien separado.
Por ejemplo,
aquí esta gente
lo tiene bastante bien,
lo tiene un poco mejor
y entonces,
bueno,
bastante en la lista
de los commits igual.
Pero hay otros
que lo tienen bastante mejor.
Por ejemplo,
Webpack
y que sí que tiene
un sistema de migración.
O sea,
que te va diciendo,
mira,
para migrar
tienes que hacer esto,
esto y esto.
A ver si lo encontramos.
Migration.
Normalmente,
a ver,
Migration.
No.
Igual es Webpack
DevServer
que lo he visto
y que me pareció
que estaba súper bien.
Pero lo tienen algunos,
¿eh?
Y no está mal.
Y ya te digo que,
mira,
Migration V4,
¿vale?
Pues te dice,
mira,
antes de actualizar,
pues ten todo esto en cuenta
y te dice,
la versión 3 hace así,
así,
ya no sé cuánto.
Yo sé lo que suelo hacer,
lo suelo mirar
y,
ves,
es que mirarse las releases
antes de actualizar,
ves realmente
de qué,
cuál es lo que está cambiando
es bastante importante
porque hay veces,
a lo mejor no aplica
a tu proyecto,
no vale la pena actualizar
y entonces,
¿para qué vas a actualizar?
Pero no te puedes fiar
del chain lock.
Hombre,
a ver,
depende de qué proyecto
te puedes fiar o no te puedes fiar,
obviamente.
En estos casos
son bastante fiables.
Además,
estos chain locks
que veis aquí
son autogenerados.
Estos chain locks
en realidad
ya están asociados
a la versión del paquete
y todo,
¿vale?
O sea,
estos commits,
al final lo que están haciendo
es que son los que van
a determinar
si se hace una release
mayor y todo esto.
¿Qué opinas
del buscador de GitHub?
A ver,
pues que es una castaña,
pero lo bueno es
new GitHub
searcher,
search,
no sé si es este.
De esa forma,
cuando saben,
puedes actualizarse
muchas vueltas.
No,
no.
Juis Negrello
dice,
hay sistemas de versiones
que están buenos,
major con cambios,
esto,
lo que justamente está comentando,
por si no lo sabéis,
es el semantic versioning,
¿vale?
El semantic versioning,
versionado semántico,
lo que quiere decir
es que la versión mayor
se cambia cuando realizas
un cambio incompatible
en la API.
La versión menor,
menor,
menor,
cuando añades funcionalidad,
compatible con versiones anteriores,
o sea,
una feature.
Y el parche sería un fix,
¿vale?
La mayor sería un breaking change,
la menor sería una feature,
y el parche sería un fix,
básicamente.
Entonces,
lo que dice Juis Negrello,
dice,
hay sistemas de versiones
que están buenos,
mayor con cambios,
medias con algunas mejoras,
y menores con fix de bugs,
y de esa forma,
cuando salen,
puedes actualizar
sin muchas vueltas.
No.
No.
Por dos motivos.
Y te voy a explicar fácilmente.
Hemos estado durante una hora
y algo
explicando la historia
de cómo una persona
ha subido una versión patch
y se ha cargado
millones de proyectos.
¿Qué te parece?
Pues eso.
O sea,
no te puedes fiar.
Es obvio.
O sea,
eso es en el mundo ideal
en el que el semantic versioning
fuese perfecto,
podrías hacerlo,
pero no es así.
No es así
porque justamente
hay mucha opinión
al respecto
o puede ser
que un fix
o una feature
rompa el paquete
y por lo tanto
debería ser una mayor.
¿Por qué?
Porque un bug
puede romper
la compatibilidad
de la API
de un paquete.
O sea,
que no.
No es fiable.
No es fiable.
No lo puedes hacer
de esa forma.
No te puedes fiar
porque la gente
utilice semantic versioning
y ya está.
No lo hagas así.
¿Vale?
Y hay otro que me gusta más
que es el compatible versioning
pero aún así
no está exento
de posibilidades.
Bueno,
después he reflexionado
un poco el salseo.
Ojo.