Issues with Lab 6.2 (Is ^2.0.0 really the same as 2.0.0)

mrmoo

---

Background info not required for my question further down

Unfortunately, the previous discussion was closed: https://forum.linuxfoundation.org/discussion/856809/issues-with-lab-6-2

However, I am still having an issue with this, in a way which hasn't yet been raised. I'm sure I'm missing some understanding here, but I need to know how the packaging system properly works.

To be clear, I understand that part of the previous discussion was regarding an update to the testing code. I have no issue with that. I also understand how and why the fastify dependency within package.json needs to be defined as "fastify": "^2.0.0".

---

My question

What I don't understand is how "fastify": "^2.0.0" will actually ever install a version "greater than or equal to 2.0.0, while accepting all future MINOR and PATCH versions".

• It begins by installing exactly 2.0.0.
• After running npm i it doesn't progress beyond version 2.0.0.
• After deleting the node_modules directory and npm i it reinstalls version 2.0.0.
• After deleting the package-lock.json and npm i it reinstalls version 2.0.0.

I trust you understand my confusion here. What is the point in defining a version above 2.0.0, if all it will ever install is version 2.0.0? What is the point in the caret (^)?

In fact, only after deleting the node_modules directory AND the package-lock.json, will it finally install a version greater than 2.0.0, when I npm i. Is this the intention - do we have to delete things to make the system work?

Or am I misunderstanding how the system works?

Thank you,

Malc

davidmarkclements

Hey Malc

Yeah it's the package-lock.json. By default the npm client adds that when you first install then locks in the dependencies. Personally I have this turned off, as you say it defeats the point of semver.

The point of lock file is to set a point in time where you lock deps for deployment purposes. Even if you take patch and minor updates you still have to trust that everyone is abiding by the bug fix/backwards compat api updates and not breaking things. Package-lock is useful for those situations where you have a large application and you want to now manually control when deps are updated. Using it from the start of a project, or for small modules, makes no sense to me personally. Imo the package-lock file should not be on by default, but that is something to take up with npm.

You can turn off package-lock with

npm config set package-lock false

And then when you actually want a package lock, you can do npm install --package-lock

mrmoo

Many thanks for explaining that, David.

It all makes perfect sense; equally, your thought, that package-lock should really be off by default.

I entirely agree with you and am going to follow your logic, turning it off until required.

Thank you!

Malc

davidmarkclements

np malc!