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