Head to database.husseinnasser.com for a discount coupon to my Introduction to Database Engineering course. Link redirects to udemy with coupon applied.
Some people think that 'npm ci' stands for "continious integration" because it mostly appears in CI build scripts. But actually it stands for "clean install". Your welcome!
Its not clean install, its simply used more in continuous integrations environments, yes it does a clean install, but its a clean install because your CI will always be a new "instance", but it also adheres strictly to the package-lock dependency versions, unlike npm install
Just run "npm ci -h" and you will see what it is. npm ci Install a project with a clean slate Usage: npm ci Options: [--no-audit] [--ignore-scripts] [--script-shell ] aliases: clean-install, ic, install-clean, isntall-clean Run "npm help ci" for more info
Great video. One command that I use to debug my packages is npm why or yarn why, shows you the dependancy graph for a given dependancy, so you can see why it was installed.
I spent months reading articles and watching videos, and none of it stuck. Hands down, the best explanation on the topic. You're doing God's work here mate!
This is definitely a good explanation! It’s frustrating when someone posted a solution for dependency related issue by removing the lock file, it get even worst especially when a package author decided to push a breaking change as a minor update.
Thank you 💗💗😊😊 sir because of your videos i am learning a lot recently I received 150% hike as Backend developer this had a positive impact on me and my family ❤️❤️ Thank you once again
Nicely explained, for the longest time I had doubts what the heck is package-lock.json or the yarn counterpart. Last week, I took some time to clear these doubts, good now. This video is now on my references list. And yes, English is hard 😢
Ah that's the reason why everytime I contribute to a nodejs codebase, the package-lock.json changes appears in my commits ! Thanks for the video, Great content 🔥
Thanks very much, 😭😭 these are the kind of explanation that help in building CI CD pipelines And for sure JavaScript project pipelines are hard to maintain
npm ci thing ... super cool. Also, if you had just given the exact version to package.json you wouldn't have to deal with package lock. In bigger projects, resolving merge conflicts when upgrading multiple packages would be a headache. So, I would suggest use exacts and use ~ only when u know u wudbe okay with minor upgrades
In: there are fish in the sea. On: there are boats on the sea. Over: Most commercial aircraft fly over the clouds. Above: Satellites are way above the clouds. Under: You find all kinds of things lost under a sofa. Beneath: If you dig enough, you might find crude oil beneath the ocean floor.
What I don't understand is, why they built npm so that "install" updates the packages. In my opinion it would be far more intuitive if only "update" updated packages and the package-lock.json file and "install" (or "restore") was the "ci" equivalent
Hussein if you work normally with node then I very highly recommend you to use another node package manager called "pnpm", it is far more efficient for managing depenedencies than just npm
@@rocstar3000 i've been using yarn since I started using nodejs for a long time and had been loving it, but after trying out pnpm I just switched as it has a really nifty way of managing your packages that I found is much better than yarn :^) Give it a go and see what you think about it ;^]
@@Abdullah-yq7jp While true, it’s not a bad choice to lock your packages down to a version. Especially if consistency and application up time are a key priority. It adds the overhead of having to monitor for exploits one way or another but it also keeps potential breaking changes out of your code base. It all depends on the package and how big of an impact it has on your application of course.
Great explanation video as always Hussein. Love your video. But I fell weird with the example of why we need to use `npm ci` If the author of project need to stick to specific version, they would not add `~` -> anyone pull and install the project would not need to run `npm ci` they can just use `npm install` as usual Btw. `npm install` already gives preference `package-lock.json`. But yarn gives preference `package.json`
6:30 this is cute. You are forgetting that even if they don't release a new version of express you can still get tons of updates, because express dependencies could have released new versions :)
NPM CI is "Clean Install". I never understood the obsession with version-ranges in the node-community. And then having to invent a lock-file when the penny dropped.
It's about giving options to developers. A person could decide to ignore the lock file while always upgrade or other teams could use the lock file more for reproducible deployments.
The docs for `npm update` explain how the semver in package.json is used. `npm install` will use package-lock.json if it's there *and compatible with `package.json`*, `npm ci` needs the lock file and will remove node_modules if that exists.
Using npm ci is the best for deployments but bad for development. Running ci can take a LONG time depending on how many packages you have, exactly because it is removing and renstalling all node_modules. We need an inbetween command which just does a diff and installs just what it needs to. Composer install honors this, why cant npm?
Because unfortunately while you can control your own packages by fixing the version, you can’t control all the dependency tree packages that downstream packages reference. One of those packages are marked as ^ or ~.
I actually had a problem a month ago where I created a gitlab auto deployment pipeline job that pulls the pushed code and runs npm install on the server and it always failed because npm install was changing the lock file on the server which was considered a change in the local git repo so the git pull fails "you have uncommited changes please stash them or commit" then I found out about npm ci and the job succeeded
so a quick question.. if you want "4.16.1" exact, then why can't you remove the ~ or ^ and it will solve the problem, no need to use package-lock.json. Am I missing something?
You might want to update the packages according to the range specified in the package.json but you don't want to do the update by accident or on a CI / build server. You then update the packages intentionally locally and check in the updated lock file.
@@PhilipLon7 if i am not confident that update won't break my app, then why would I take the risk of updating more than 1 package at a time? And if I am updating only 1 package, then i can do it manually.
Head to database.husseinnasser.com for a discount coupon to my Introduction to Database Engineering course. Link redirects to udemy with coupon applied.
Some people think that 'npm ci' stands for "continious integration" because it mostly appears in CI build scripts. But actually it stands for "clean install". Your welcome!
Its not clean install, its simply used more in continuous integrations environments, yes it does a clean install, but its a clean install because your CI will always be a new "instance", but it also adheres strictly to the package-lock dependency versions, unlike npm install
Just run "npm ci -h" and you will see what it is.
npm ci
Install a project with a clean slate
Usage:
npm ci
Options:
[--no-audit] [--ignore-scripts] [--script-shell ]
aliases: clean-install, ic, install-clean, isntall-clean
Run "npm help ci" for more info
@@KingTheRat Ah the wonders of the internet. :) Thanks for this valuable information.
... who tf assumed it meant "continuous integration"? No real developer would think that. Seriously. That's ridiculous.
@@flannelbeard4621 Me.
I assumed it as continuous integration, seriously.
Great video. One command that I use to debug my packages is npm why or yarn why, shows you the dependancy graph for a given dependancy, so you can see why it was installed.
I see you've reached to this video even before me 😂
I watch your videos here and there. Good content
@@sidwebworks9871 You've got to be quick!
I spent months reading articles and watching videos, and none of it stuck. Hands down, the best explanation on the topic. You're doing God's work here mate!
This is definitely a good explanation!
It’s frustrating when someone posted a solution for dependency related issue by removing the lock file, it get even worst especially when a package author decided to push a breaking change as a minor update.
I've come across this explanation before, but it never quite stuck. I appreciate your communication style, thanks!
LOOL 4:03 "Keep the major version out of your F** mouth!" that made me laugh so hard
Thank you 💗💗😊😊 sir because of your videos i am learning a lot recently I received 150% hike as Backend developer this had a positive impact on me and my family ❤️❤️
Thank you once again
Congrats to you! I too recently got a pay hike. Feels really validating.
will-package-smith @4:04 reporting for slapping
omg ! I didn't get the reference until I read your comment , and for that I thank you.
Hi. That was great explaination between package.json and package-lock.json files.
Well done.
thanks bro now i can never forget the difference
Computer: knows 0 and 1
Hussein sir: **pathetic**
Nicely explained, for the longest time I had doubts what the heck is package-lock.json or the yarn counterpart. Last week, I took some time to clear these doubts, good now. This video is now on my references list.
And yes, English is hard 😢
"Keep the major version out of your f***ing mouth"
- Nasser 2022
Good refresher 👌
I read somewhere that the ci stands for clean install?
i just subbed because you said "KEEP THE MAJOR VERSION OUT OF YOUR F*ING MOUNTH !"
The best one I've ever seen on this topic..Thanks.
Hussein, this video is gold! Really well explained. I didn’t know about ‘npm ci’ - how handy! 👍🏽🔥
Thank you!!!!!! Super clear explanation.
Please do one on peer dependencies in package lock json if you get the time and interest ❤️
Thanks for adding humour in teaching
Man you are awesome. You explain engineering concept so well.
Thanks Hussein for covering this topic !
Ah that's the reason why everytime I contribute to a nodejs codebase, the package-lock.json changes appears in my commits ! Thanks for the video, Great content 🔥
Thanks very much, 😭😭 these are the kind of explanation that help in building CI CD pipelines
And for sure JavaScript project pipelines are hard to maintain
Hello Husein. Thanks for video. I learned a lot from this. I really appreciate what you are sharing us.
Thank you Hussein, happy Ramadan bro. 🌹🌹
npm ci thing ... super cool.
Also, if you had just given the exact version to package.json you wouldn't have to deal with package lock.
In bigger projects, resolving merge conflicts when upgrading multiple packages would be a headache.
So, I would suggest use exacts and use ~ only when u know u wudbe okay with minor upgrades
I recognized this name somewhere🤩Great nginx course on Udemy
it's "set IN stone" imagine carving INto a stone is more permanent than drawing ON a stone ;) thanks for the video
great explanation Nasser.
Some where I read npm ci is for clean install, LOL!. Finally understood what that npm ci does. Gonna change my gitlab pipelines.
This video is different. But positive with much of humour. Thanks
In: there are fish in the sea. On: there are boats on the sea. Over: Most commercial aircraft fly over the clouds. Above: Satellites are way above the clouds. Under: You find all kinds of things lost under a sofa. Beneath: If you dig enough, you might find crude oil beneath the ocean floor.
Great content! And also a touch of sense of humor. We need to add a little fun to our learning process.
What I don't understand is, why they built npm so that "install" updates the packages.
In my opinion it would be far more intuitive if only "update" updated packages and the package-lock.json file
and "install" (or "restore") was the "ci" equivalent
Awesome explanation!!! Thank you so much for providing this knowledge.
great explanation, I had always wondered the utility of package-lock.json, now I know it
you can use "npm shrinkwrap'' it'll help you to lockdown the versions of installed packages and their descendant packaages.
Hussein if you work normally with node then I very highly recommend you to use another node package manager called "pnpm", it is far more efficient for managing depenedencies than just npm
I use yarn :)
@@rocstar3000 i've been using yarn since I started using nodejs for a long time and had been loving it, but after trying out pnpm I just switched as it has a really nifty way of managing your packages that I found is much better than yarn :^)
Give it a go and see what you think about it ;^]
great explanations
Finally got it...thanks :)
Could we just not use ~ or ˆ in the package.json to lock the version?
Yes - but any vulnerability found, patched will remain in your code that can be exploited!!
@@Abdullah-yq7jp
While true, it’s not a bad choice to lock your packages down to a version. Especially if consistency and application up time are a key priority. It adds the overhead of having to monitor for exploits one way or another but it also keeps potential breaking changes out of your code base.
It all depends on the package and how big of an impact it has on your application of course.
So should we always use npm ci all the time instead of npm install just to be safe??
👍 Good simplification
Great explanation. Please make a very detailed playlist of nodejs 🙏
Hahahaha the Will Smith part was so funny and unexpected
Great explanation, thank you !!!
We also have npm-shrinkwrap.json , when we run npm ci and if our project doesn't have package-lock.json, npm CI considers shrinkwrap.json
Haha 😆. Have you considered doing podcast. You are funny and yet so knowledgeable to the topic.
"Don't touch my minor" 😂
PLEASE START A DISCORD SERVER CAUSE YOUR CONTENT IS ABSOLUTE GOLD.
I think the CI in npm ci stands for "Current Install"
Great explanation video as always Hussein. Love your video.
But I fell weird with the example of why we need to use `npm ci`
If the author of project need to stick to specific version, they would not add `~` -> anyone pull and install the project would not need to run `npm ci` they can just use `npm install` as usual
Btw. `npm install` already gives preference `package-lock.json`.
But yarn gives preference `package.json`
This whole time I have been deleting package-lock.json just because VS Code complains about it too much. 😂
Good video. Thank you Hussein!
Hey @hnasr, how to decide whether to use carrot or tilda ?
damn Im using npm for years now I didnt know `npm ci` existed until now. this is very helpful
"will smith" reference caught me off guard
Loved it!
This is gold 🥇
Why introducing a concept of package-lock.json? I need exact version? I can remove tilda. Why overcomplicating things?
Amazing video! npm ci is actually clean install, it has nothing to do with CI/CD!
Awesome ❤
great video and your english is good! :)
Very clear. Big up to Will smith
Straight to my gitlab CI/CD codebase and updating all npm install commands to npm ci
Omg I lost it at the will smith reference lmao
This is amazing
6:30 this is cute. You are forgetting that even if they don't release a new version of express you can still get tons of updates, because express dependencies could have released new versions :)
awesome video man!
Always use npm ci on the build pipeline!
Why should i depends on package_lock if i can fix (without adding ^ and ~ ) my version in package.json ? 🤔
NPM CI is "Clean Install".
I never understood the obsession with version-ranges in the node-community.
And then having to invent a lock-file when the penny dropped.
It's about giving options to developers. A person could decide to ignore the lock file while always upgrade or other teams could use the lock file more for reproducible deployments.
What MacBook are you using?
It would be nice if adding "$" restricts only patch updates.
The will smith troll was hilarious 😂😂
The docs for `npm update` explain how the semver in package.json is used. `npm install` will use package-lock.json if it's there *and compatible with `package.json`*, `npm ci` needs the lock file and will remove node_modules if that exists.
Using npm ci is the best for deployments but bad for development. Running ci can take a LONG time depending on how many packages you have, exactly because it is removing and renstalling all node_modules. We need an inbetween command which just does a diff and installs just what it needs to. Composer install honors this, why cant npm?
npm ci means clean install tho right ?
So why should I use npm ci instead of just locking the specific version directly on my package.json? That's what confuses me ☹️
Because unfortunately while you can control your own packages by fixing the version, you can’t control all the dependency tree packages that downstream packages reference. One of those packages are marked as ^ or ~.
@@hnasr that makes a lot of sense. Thanks!!! Love your videos
I actually had a problem a month ago where I created a gitlab auto deployment pipeline job that pulls the pushed code and runs npm install on the server and it always failed because npm install was changing the lock file on the server which was considered a change in the local git repo so the git pull fails "you have uncommited changes please stash them or commit" then I found out about npm ci and the job succeeded
Wow interesting! I bet it was nasty to find
good to see you using vim :)
pnpm alternative for npm
so a quick question.. if you want "4.16.1" exact, then why can't you remove the ~ or ^ and it will solve the problem, no need to use package-lock.json. Am I missing something?
You might want to update the packages according to the range specified in the package.json
but you don't want to do the update by accident or on a CI / build server.
You then update the packages intentionally locally and check in the updated lock file.
@@PhilipLon7 if i am not confident that update won't break my app, then why would I take the risk of updating more than 1 package at a time? And if I am updating only 1 package, then i can do it manually.
I feel like he went full scottish for the 'caret'
Upvote
Awesome
This seems like a nightmare for enterprises. Do they physically host their own approved repositories?
Yes most enterprises I suppose would have a controlled npm registry. Otherwise its a mess.
Love it 😂
lmao at Will Smith part
Hussein Smith
ci=clean-install
the ''carrot''
$ npm ci
Great job dude! thanks for sharing
❤️
vim is giving me anxiety.
🔥🔥🔥
green
Node package management is a huge mess...
talking head thing XD