No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Package lock y el uso los s铆mbolos ^ y ~

8/15
Recursos

El archivo package-lock.json describe todo el 谩rbol de dependencias de cada paquete instalado. Cuando alguien hace fork de un repositorio no tiene el directorio node_modules.

Con el comando npm install se instalar谩n las dependencias indicadas en el package.json con la versi贸n indicada. Tambi茅n, se instalar谩n las sub-dependencias indicadas en package-lock.json con la versi贸n indicada. Pero, 驴qu茅 significan estas diferentes versiones en cada dependencia?

Versionado de paquetes

El versionado de paquetes est谩 conformado por tres valores:

  • Major: el valor que muestra la versi贸n que contiene los cambios importantes del paquete
  • Minor: el valor que muestra la versi贸n que contiene los cambios en funcionalidades, pero no representan un cambio significativo
  • Patch: el valor que muestra la versi贸n que contiene cambios r谩pidos para solucionar problemas de seguridad o bugs
versionado

S铆mbolos ^ y ~ para actualizar las versiones minor y patch

Existen dos s铆mbolos que acompa帽an a este versionado, que sirven para actualizar las versiones minor y patch del paquete:

  • Caret (^): Permite actualizar las versiones minor y patch
  • Tilde (~): Permite actualizar las versiones patch

Por ejemplo, tenemos la versi贸n 鈥5.2.3鈥:

  • Si tiene el carret ^, actualizar谩 la versi贸n minor y patch, por lo que tendr谩s versiones como 鈥^5.3.3鈥, 鈥^5.4.3鈥, 鈥^5.4.4鈥, etc.
  • Si tiene la tilde ~, actualizar谩 la versi贸n de patch, por lo que tendr谩s versiones como 鈥~5.2.4鈥, 鈥~5.2.5鈥, 鈥~5.2.6鈥, etc.

Lo recomendable es quitar estos s铆mbolos y tener la versi贸n exacta para evitar problemas de versionado, principalmente con paquetes que los mantienen pocas personas o no son fiables.

Contribuci贸n creada con aportes de: Andr茅s Guano.

Aportes 58

Preguntas 19

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Reg铆strate o inicia sesi贸n para participar.

Adem谩s de esos s铆mbolos, tambi茅n tenemos:

  • < : Versi贸n menor a la indicada.
  • <= : Versi贸n menor o igual a la indicada.
  • > : Versi贸n mayor a la indicada.
  • >= : Versi贸n mayor o igual a la indicada.

Los cuales se utilizan as铆:

"dependencies": {
    "json-server": ">0.15.1",
    "moment": ">=2.26.0",
    "date-fns": "<2.14.0",
     "react": "<=16.12.0"
}
  • ^ = Si mantenemos el caret dentro de la configuraci贸n de nuestro package estamos garantizando que cuando realicemos una actualizaci贸n o tengamos un cambio que podamos realizar, vamos a hacer actualizaci贸n de los cambios menores y de los parches o bug fixes.
    Para quedarnos en una sola versi贸n eliminamos el caret.

  • ~ = Establece que vamos a recibir actualizaciones o cambios solamente de los cambios que son parches o bug fixes.

Nombre en espa帽ol de los s铆mbolos utilizados

^ Acento circunflejo
~ Virgulilla
<h3>Versionado Sem谩ntico</h3>

En el versionado tenemos 3 d铆gitos que significa:

  • Primer d铆gito: son cambios mayores
  • Segundo d铆gito: a帽aden ciertas funcionalidades pero no representan un gran paso para decir que esta es una versi贸n nueva
  • Tercer d铆gito: estos son patch, bug fixes o cambios menores

*Cuando tenemos el s铆mbolo (^) catet dentro de la configuraci贸n del package.json estamos garantizando que cuando nosotros hagamos una actualizaci贸n o tengamos un cambio que podamos realizar, vamos a hacer actualizacion solo de los cambios menores y de los parches o bug fix de este paquete.

*tambi茅n podemos establecer una tilde (~) esto quiere decir que vamos a recibir actualizaci贸n o cambios que son parch o bug fixes.

*Lo recomendo si queremos tener el control sobre estas actualizacion garantizando que nos queremos quedar en cierta versi贸n lo mejor es elimina el caret (^)

Package-lock.json a partir de la versi贸n 5 npm encontramos este archivo que nos permite tener ciertas configuraciones la cual nos permite saber que esta sucediendo a lo largo de nuestro proyecto sabiendo que versiones, que paquetes y que dependencias se encuentran en este, permitiendonos tener un versionado uno poco mas establecido, podremos compartir este documento con los dem谩s desarrolladores y garantizar que las versiones que se est谩n instalando sean las correctas, al igual nos sirve para cuando los proyectos est茅n en la nube y nuestro servidor instale de manera autom谩tica todas estas dependencias

Comando:
git clone https://github.com/gndx/react-base.git && cd react-base

Hasta donde sab铆a, el package-lock era como un mapa m谩s detallado de nuestro proyecto, el cual ya ten铆a todas las versiones y todo escrito para que npm unicamente las instalara sin tener que volver a hacer una b煤squeda, etc.

Y como resumen, en teor铆a cuando usas 鈥淾鈥 permites el update de cambios menores y cuando usas 鈥渵鈥 permites el update de bugfixes unicamente, y esto es 煤til para aquellos servicios que hacen los updates de nuestros paquetes autom谩ticamente ^^

Es recomendable subir el package lock al repositorio? O se debe excluir con el gitignore?

Package.json vs Package-lock.json

Estos dos archivos son el coraz贸n del manejo de dependencias de un proyecto en Node.

Package.json contiene mas informaci贸n sobre el proyecto en si, y establece las dependencias principales del proyecto.

Package-lock.json guarda mas informaci贸n sobre las dependencias. Por ejemplo: si estamos utilizando Express.js, esta estar谩 referenciada en el package.json como dependencia, pero Express a su vez contiene 30 dependencias mas y 18 dependencias de desarrollo. Adem谩s de almacenar otra informaci贸n importante como la version de las mismas. Esta informaci贸n estar谩 contenida en el package-lock.json.

La mejor manera de guardar nuestras dependencias a utilizar con una versi贸n exacta es indicando la siguiente bandera:

npm install --save-exact nombreDelPaquete

o en su versi贸n corta:

npm i -E nombreDelPaquete

Les dejo este recurso que me salvo de algunos problemas de colisiones de versiones en mi ambiente de CI/CD, ademas, es la recomendaci贸n de NPM para versionar nuestro package-lock.json

npm shrinkwrap

https://docs.npmjs.com/cli/shrinkwrap.html

Me li茅 con algunas cosas y por eso quisiera resumir algunas cosas de todo lo que he leido.
聽聽
1. Por defecto el package.json nunca va a instalar major versions, esto es debido a que un cambio grande (por ejemplo 1.1.1 a 2.0.0) podr铆a incluir y excluir cosas que dejen inservible a nuestro proyecto

2. El package-lock.json se llama asi debido a como su nombre lo dice se quiere bloquear/asegurar (lock) el codigo. Antes de la version 5 de npm que fue lanzada en 2017 habian problemas, ya que hay que tener en cuenta que no solo las dependecias sino las subdepencias ( es decir dependencias que por defecto traen el paquete que deseas instalar) pueden actualizarse rompiendo el codigo, por eso el package lock json es literal un screenshot de las versiones de todas las dependencias y subdependencias que tengas.

3. Si no tienes package lock, se instalaran las dependecias mas recientes segun como hayas usado los simbolos ^ y ~ en tu package.json. Si tienes package lock se instalaran exactamente las versiones que se encuentren en el mismo

4. Al usar npm update se actualizaran tus dependencias segun ^ y ~ (el versionado semantico ) , pero no se actualizaran major versions. Adicionalmente si estas debajo de la version 1.0.0 la virgulilla ~ se comportara diferente (por ejemplo si estas en la version 0.15.0 solo podras actualizar hasta 0.15.x , no la 0.16.0).

Espero te sirva 馃槂

Les dejo este link de uno de lso chicos y uff me sirvio para entender la forma de aplicar la clase!

https://fperez217.medium.com/qu茅-es-versionamiento-![Captura de Pantalla 2021-06-22 a la(s) 23.31.26.png]

BLOG
https://fperez217.medium.com/qu茅-es-versionamiento-sem谩ntico-bf495b9eb028

Fuente
See semver for more details about specifying version ranges.

version Must match version exactly
>version Must be greater than version
>=version etc
<version
<=version
~version 鈥淎pproximately equivalent to version鈥
^version "Compatible with version"
1.2.x 1.2.0, 1.2.1, etc., but not 1.3.0
https://... See 鈥楿RLs as Dependencies鈥 below
* Matches any version
"" (just an empty string) Same as *
version1 - version2 Same as >=version1 <=version2.
range1 || range2 Passes if either range1 or range2 are satisfied.
git鈥 See 鈥楪it URLs as Dependencies鈥 below
user/repo See 鈥楪itHub URLs鈥 below
tag A specific version tagged and published as tag See npm dist-tag
path/path/path See Local Paths below
For example, these are all valid:

{
  "dependencies": {
    "foo": "1.0.0 - 2.9999.9999",
    "bar": ">=1.0.2 <2.1.2",
    "baz": ">1.0.2 <=2.3.4",
    "boo": "2.0.1",
    "qux": "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0",
    "asd": "https://asdf.com/asdf.tar.gz",
    "til": "~1.2",
    "elf": "~1.2.3",
    "two": "2.x",
    "thr": "3.3.x",
    "lat": "latest",
    "dyl": "file:../dyl"
  }
}

El archvo package-lock.json sirve para bloquiar la version de las dependencias (lock como su nombre lo dice), si bien el archivo package.json define las dependencias y en que version deben estar, no es muy exacto, ya que este archivo maneja constrains (^, ~, >=) lo que deja una gran variedad de opciones validas a usar.

entonces otro desarrollador que colabore con nosotros va a adivinar que version exacta ocupamos nostros???
la respuesta es no, cuando npm instala un paquete, lo agrega en el package.json con un constrain (para dejarlo avierto a la actualizacion)
pero especifica que vercion exacta se uso en el momento que un desarrollador la instalo en el archivo package-lock.json y ademas tambien especifica las dependencias de nuestras depenencias ahi mismo

El archivo package-lock.json si se sube a los repositorios o producci贸n?

git clone https://github.com/gndx/react-base.git && cd react-base
git clone https://github.com/gndx/react-base.git

Versionado de paquetes dentro de package.json :

^ caret (acento circunflejo): Especifica que el paquete se va a actualizar hasta la 煤ltima versi贸n menor.

~ tilde (virgulilla): Mantiene el paquete hasta el 煤ltimo parche.

Sin ning煤n s铆mbolo: Mantiene la versi贸n exacta del paquete especificada en el package.json

Repositorio que clono:
git clone https://github.com/gndx/react-base.git

Package lock y el uso de los s铆mbolos ^ y ~

<h3>鉅</h3>


Entenderemos la importancia del versionado sem谩ntico y el archivo package.log.

Una de las cosas que podemos notar son los elementos 鈥榐鈥 que se refiere a un valor en el versionado.

La forma correcta de manejar versionado es la siguiente:



Como desarrolladores queremos garantizar que nos quedemos en una sola version.

Eliminando el caret (^) podemos garantizar que nos quedamos en la curren version de la dependencia.

Esto nos permite tener un versionado mas establecido, podremos compartir el documento con los dem谩s desarrolladores y garantizar que las versiones instaladas sean las correctas. Igual si lo subimos a la nube nos aseguramos que este siga funcionando.

Les comparto un tutorial de c贸mo funciona este sistema de versionado sem谩ntico as铆 como tambi茅n todos los s铆mbolos que podemos usar en nuestro package.json para establecer reglas para nuestras versiones:
.
https://platzi.com/tutoriales/1763-npm/8399-como-funcionan-las-versiones-en-npm/

Que es package-lock

Tanto tiempo trabajando con node y hasta ahora me doy cuenta que signioicaba algo esos simbolos!. Buena clase.

Ahora tengo claro el significado de estos s铆mbolos y como puedo modificarlos si quiero que un paquete siempre tenga una versi贸n o se actualice ciertos segmentos de la versi贸n. Muchas gracias por la clase instructor Oscar.

El versionamiento es algo que debemos conocer bastante bien para nuestras aplicaciones.
Adem谩s de los cambios Major - Minor - Patch, debemos entender las etiquetas de pre-lanzamiento, en qu茅 momento est谩 en Beta o en Alpha nuestra aplicaci贸n? Y c贸mo llevar el flujo de la misma!
Te dejo un blogpost para que puedas saber m谩s al respecto 馃槈

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
This file is intended to be committed into source repositories, and serves various purposes:

  1. Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
  2. Provide a facility for users to 鈥渢ime-travel鈥 to previous states of node_modules without having to commit the directory itself.
  3. To facilitate greater visibility of tree changes through readable source control diffs.
  4. And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.

More information: https://docs.npmjs.com/cli/v6/configuring-npm/package-lock-json

Package lock y el uso los s铆mbolos ^ y ~

El versionado sem谩ntico es un numero que cada paquete tiene y puede ir cambiando aumentando pues cada actualizaci贸n aumentara un digito, seg煤n el digito que aumente as铆 tambi茅n ser谩 el tipo de actualizaci贸n.

{
  react : ^16.11.0,
  eslint: ~0.4.0
}

Primer digito indica un cambio mayor, el siguiente digito indica que el cambios es menores por ejemplo a帽adir nuevas funcionalidades pero no son un cambio mayor en el proyecto, y por ultimo podemos hacer cambio menores, parches o alg煤n fixbug.

Si en el archivo package.json mantenemos el caret(^) estamos queriendo decir que solo vamos a recibir actualizaci贸n de cambio menores y fixbug, tambi茅n podemos establecer una tilde (~) e indica que solo tendremos actualizaciones de tipo fixbug o parches.

Adem谩s a partir de la versi贸n 5 de npm tendremos un archivo package-lock.json que hace una recopilaci贸n de los paquetes y versiones que se han instalado en nuestro proyecto.

Buenas practicas

Muchas veces como desarrolladores queremos garantizar quedarnos en cierta versi贸n y para lograr esto se debe eliminar en el archivo package.json el caret o la tilde (^ o ~).

<h3>Versionado con npm</h3>

Dependiendo del simbolo que tengamos en el package.json por cada version, podemos controlar como queremos o no recibir actualizaciones de las dependencias.

  • ^ Este simbolo garantizara que solo recibamos cambios menores y de bug fixes como actualizacion.
  • ~ Establece que vamos a recibir actualizaciones o cambios solamente de los que son parches o bug fixes.

Adem谩s de esos s铆mbolos, tambi茅n tenemos:

  • <聽 Versi贸n menor a la indicada.
  • <= Versi贸n menor o igual a la indicada.
  • > ****Versi贸n mayor a la indicada.
  • >= Versi贸n mayor o igual a la indicada.

Los cuales se utilizan as铆:

"dependencies": {
		"webpack": "**^3.1.2",
		"xmlhttprequest": "~8.4.3",**
    "json-server": ">0.15.1",
    "moment": ">=2.26.0",
    "date-fns": "<2.14.0",
     "react": "<=16.12.0"
}

En esta herramienta pueden hacer pruebas con las versi贸nes de los packages de npm

semvernpm

No entend铆 la importancia o lo que resuelve el archivo package-log

Este par de publicaciones pueden complementar bastante acerca del versionado sem谩ntico el cual fue creado por Tom Preston-Werner (Creador de Gravatar y cofundador de GitHub)
https://semver.org/
https://docs.npmjs.com/about-semantic-versioning

El versionado de nuestros paquetes pueden tener algunas simbolog铆as que dan ciertas instrucciones a npm a la hora de actualizar los paquetes.

Tomemos los siguientes ejemplos:

"dependencies": {
  "jshint": "^2.8.0"
}

Para: ^ se le actualizara a la ultima gran version (el primer n煤mero). ^ 2.8.0 coincidir谩 con cualquier 2.x.x de liberaci贸n incluyendo 2.9.0,pero manteniendo la distancia de la version 3.0.0

"dependencies": {
  "jshint": "~1.8.0"
}

Para : ~ 1.8.0 coincidir谩 con todas las 1.8.x versiones, pero se perder谩 1.9.0 (Este ha sido el comportamiento predeterminado).

Cuando encontramos una version sin ning煤n s铆mbolo, como este:

"dependencies": {
  "jshint": "1.8.0"
}

Significa que queremos utilizar exactamente esa version.

hay mas informacion sobre esto en el siguiente link 馃槉 https://bytearcher.com/articles/semver-explained-why-theres-a-caret-in-my-package-json/

Cuando tenemos ciertas dependencias en nuestro proyecto, podemos ver en el package.json el elemento de 鈥榐鈥 junto a las versiones, esto es el manejo de versionado que podemos ver:

Aqui podemos ver al forma de manejar el versionado, donde el primero sera un cambio mayor, despues un cambio menor, donde cambian ciertas funcionalidades pero no tan grandes para ser una version nueva. Despues tenemos algunos parches que arreglan algunos errores.
Si nosotros mantenemos el CARET(^) dentro de nuestra configuracion en nuestro package.json, al momento de actualizar o realizar cambios, sol ose acutalizara los cambios menores y los parches o bug fixing. Si nosotros establecemos una TILDE(~) solo se actualizaran los parches o bug Fixing.

En el archivo Package-lock que nos permitira tener ciertas configuraciones para entender a lo largo del proyecto, que es lo que esta sucendiendo. Nos ayuda a tener un versionado mas exacto de lo que esta sucediendo.

Por si alguno necesita el comando.
git clone https://github.com/gndx/react-base.git && cd react-base

El profesor Oscar es grandioso explicando, dan ganas de aprender mucho cuando lo escuchas

Que excelente profesor es Oscar.

Definitivamente Oscar es una gran profesor, genial como explica.

Manejo de versionado鈥
3.9.2
3 --> Cambios mayores.
9 --> Cambios menores, no relevantes.
2 --> Arreglos menores, como bugs.

Entendido

git clone https://github.com/gndx/react-base.git && cd react-base
^ = alt + 94
= alt + 126

En el archivo package-lock.json, se van a especificar las versiones de las dependencias de manera exacta. Sin embargo, las dependencias se definen por los n煤meros de sus diferentes versiones, y estas van desde lo m谩s a lo menos importante (de izquierda a derecha).

  • Major: Nueva versi贸n
  • Minor: Nuevos features peque帽os
  • Patch: Arreglo de Bugs

驴C贸mo saber qu茅 exactamente se va actualizar en nuestro paquete instalado? Depende de qu茅 s铆mbolo le anteceda:

^3.9.2 : Minor y Patch

~3.9.2 : Solo Patch
.
.
.
Esta es mi nota de la clase, ojal谩 sea de ayuda para alguien 馃槂

^ El caret: obliga a que tu package solo sea actualizado para los cambios menores y parches

  • Asterisco: Obliga a tu package que solo se pueda actualizar en los parches
    sin un prefijo: obliga a que solo nos quedemos con la versi贸n seteada

VIRGULILLA,NO TILDE ~

En powershell para concatenar comandos se utiliza el punto y coma en lugar de &&.

Algo tarde, pero ahora me esta quedando todo claro.

buena clase

No me hab铆a quedado muy clara la diferencia entre package.json y package-lock.json , por eso estuve buscando y encontr茅 este video https://www.youtube.com/watch?v=9xaKQi9-VTI&t=369 me ayud贸 mucho. Lo 煤nico, est谩 en ingl茅s.

Las versiones se deben manejar de la siguiente manera:
V 1.63
El primer n煤mero [ 1 ] = representa un cambio mayor, como ejemplo el nuevo home de Platzi.
El segundo n煤mero [ en este caso 6] = representa nuevas cosas que se a帽aden a la app pero no son un gran cambio, como por ejemplo el bot贸n de a帽adir o borrar un curso de alguna ruta.
Y el 煤ltimo n煤mero [ el 3 ] representa correcciones a errores o bugs de la app

SIMBOLOS EN PACKAGE-LOCK.JSON
.
status de una dependencia
1 - 2 - 3
2.15.7
.
1: VERSION
2: PARCHES
3: BUG FIX
.
Para quedarnos en una sola versi贸n eliminamos no usamos simbolos.
^ = Para actualizar parches y bug fixes
~ = Actualizar bug fixes.

1.4.3

a

Interesante

Me est谩 quedando mucho m谩s claro todo

Para instalar una versi贸n exacta se puede usar** --save-exact**

npm install package_name --save-exact, (鈥減ackage_name鈥: 鈥4.1.3鈥).