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
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!
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.
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.
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 😢
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
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 ;^]
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.
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 🔥
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
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
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
@@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.
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.
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`
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
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 ~.
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.
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?
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.
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!
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!
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!
The best one I've ever seen on this topic..Thanks.
"Keep the major version out of your f***ing mouth"
- Nasser 2022
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 😢
LOOL 4:03 "Keep the major version out of your F** mouth!" that made me laugh so hard
Hi. That was great explaination between package.json and package-lock.json files.
Well done.
Man you are awesome. You explain engineering concept so well.
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.
thanks bro now i can never forget the difference
Hussein, this video is gold! Really well explained. I didn’t know about ‘npm ci’ - how handy! 👍🏽🔥
Computer: knows 0 and 1
Hussein sir: **pathetic**
Thank you Hussein, happy Ramadan bro. 🌹🌹
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 ;^]
Thanks Hussein for covering this topic !
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.
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 🔥
Thank you!!!!!! Super clear explanation.
Please do one on peer dependencies in package lock json if you get the time and interest ❤️
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
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.
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
Thanks for adding humour in teaching
Hello Husein. Thanks for video. I learned a lot from this. I really appreciate what you are sharing us.
Good refresher 👌
I read somewhere that the ci stands for clean install?
you can use "npm shrinkwrap'' it'll help you to lockdown the versions of installed packages and their descendant packaages.
Great content! And also a touch of sense of humor. We need to add a little fun to our learning process.
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
Some where I read npm ci is for clean install, LOL!. Finally understood what that npm ci does. Gonna change my gitlab pipelines.
great explanation Nasser.
I recognized this name somewhere🤩Great nginx course on Udemy
This video is different. But positive with much of humour. Thanks
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
it's "set IN stone" imagine carving INto a stone is more permanent than drawing ON a stone ;) thanks for the video
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.
Awesome explanation!!! Thank you so much for providing this knowledge.
i just subbed because you said "KEEP THE MAJOR VERSION OUT OF YOUR F*ING MOUNTH !"
great explanation, I had always wondered the utility of package-lock.json, now I know it
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 :)
Finally got it...thanks :)
Great explanation. Please make a very detailed playlist of nodejs 🙏
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.
PLEASE START A DISCORD SERVER CAUSE YOUR CONTENT IS ABSOLUTE GOLD.
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`
awesome video man!
Hey @hnasr, how to decide whether to use carrot or tilda ?
So should we always use npm ci all the time instead of npm install just to be safe??
Why should i depends on package_lock if i can fix (without adding ^ and ~ ) my version in package.json ? 🤔
Great explanation, thank you !!!
great video and your english is good! :)
This is gold 🥇
damn Im using npm for years now I didnt know `npm ci` existed until now. this is very helpful
Good video. Thank you Hussein!
I think the CI in npm ci stands for "Current Install"
"Don't touch my minor" 😂
This whole time I have been deleting package-lock.json just because VS Code complains about it too much. 😂
Loved it!
This is amazing
Haha 😆. Have you considered doing podcast. You are funny and yet so knowledgeable to the topic.
Amazing video! npm ci is actually clean install, it has nothing to do with CI/CD!
👍 Good simplification
Very clear. Big up to Will smith
great explanations
Why introducing a concept of package-lock.json? I need exact version? I can remove tilda. Why overcomplicating things?
What MacBook are you using?
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
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
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.
Hahahaha the Will Smith part was so funny and unexpected
It would be nice if adding "$" restricts only patch updates.
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?
Awesome ❤
"will smith" reference caught me off guard
Straight to my gitlab CI/CD codebase and updating all npm install commands to npm ci
Always use npm ci on the build pipeline!
npm ci means clean install tho right ?
The will smith troll was hilarious 😂😂
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.
good to see you using vim :)
Omg I lost it at the will smith reference lmao
I feel like he went full scottish for the 'caret'
Love it 😂
Awesome
Upvote
pnpm alternative for npm
🔥🔥🔥
$ npm ci
Great job dude! thanks for sharing
Node package management is a huge mess...
❤️
Hussein Smith
ci=clean-install
the ''carrot''
vim is giving me anxiety.
lmao at Will Smith part
green
🤣🤣🤣👍👍
talking head thing XD