0:49 NPM isn’t slow, it just gives you time to make a drink, have a shower, go for a run, get much needed 12hr sleep. It’s a feature for larger projects 😅
@@szmr I got two computers. One that is really old windows and a new windows. Same everything installs 15minutes on my old computer, and a few second to a minute on my new one. That's like 15x difference
it's single-threaded, so only higher core clock speed would make a difference, and that is not easy to come by. intel i9 14900K costs a fortune @@aurelianspodarec2629
I like how React projects have so many dependencies that instead of solving that problem with common patterns and packages combined they decided to build a fast dependency installer.
After trying Fresh for Deno and seeing that it only installs 300 files total for its deps (not packages, 300 TS files, and most of them are just Deno stdlib stuff) it kind of makes me never want to touch any Node/React stuff again lol
Well, it's arguably a good thing that there's so many packages as it's less work for 1 team and much more control over what you install. Of course it is slower though.
pnpm is great but it definitely needs more work in properly hoisting packages during builds, specifically on monorepos with web and mobile like nextjs and expo.
I perfer to use pnpm when I can. But for projects with loads of dependencies, compatibility with pnpm have so far been kind of a pain in the ass, while yarn can handle those projects without any issue, albeit a bit slower.
You should have shown the node_modules folder! With pnpm all the sub dependencies hidden in a subfolder. So when you open node_modules you will just the dependencies defined in your package.json (plus a few extra folders)
I don't know why, but I tried it a while ago and for some reason, typing "pnpm" gave me some kind of keyboard dyslexia and I would always end up typing some other permutation of those letters. Lol.
Really glad that PNPM is catching on more and more. I made a pull request a few months ago to add PNPM support to replit/upm and I'm so glad I did that - just so that more people can be introduced to PNPM.
Conflicts in lockfiles is a huge issue. I am happy to hear in your case the pnpm lockfile had less conflicts than the alternatives. We did work a lot on minimising the amount of lockfile conflicts. Unfortunately, there is no way to completely avoid conflicts. We have some experimental settings for creating lockfiles with different names on branches. The idea is that once the branch is merged, a job merges the lockfiles and commits the updated "pnpm-lock.yaml" to the main branch, avoiding conflicts altogether.
Super weird to see pnpm succeeding. I started using it in 2018. I even filed an issue because it originally didn't work for AngularJS at all. I tried to get others in the company to start using it (i'm not a frontend dev, npm really just sucks when you have all the nice tools the backend has), but no one wanted to. It's great to finally see it succeeding. At my current company I think several teams are using it!
I definitely enjoy seeing the count of reused packages when I install a new package. Only problem is using npm for work and then accidentally doing npm i for a personal project then panic ctrl+c when I forget to use pnpm
A colleague of mine told me about it a few years ago, and once I tried it I never looked back. The biggest thing for me, that you didn't mention in this video, was workspaces! It makes setting up monorepos is super-easy.
We used pnpm in production on a monorepo and it caused all kinds of issues with dependencies, using incorrect versions and leading to high memory usage. We now swapped it for yarn again and all out issues disappeared.
dude, you frickin rock! i just had a seemingly unsolvable dependency issue in a prod application, saw this video, tried pnpm, and it just magically started working again. what a g!
Wowww! This is the first time I've ever needed to slow down ⏬⏬⏬ a video instead of speeding it up ⏩⏩to 1.25x or 1.5x like I usually do. To be clear, I mean this as a compliment - your rapid-fire delivery packs so much valuable information into such a short time, all while maintaining perfect clarity. I'm impressed. Keep up the fantastic work!
pnpm scares me, we had a memory leak with a monorepo every time it recompiled it was creating a bigger memory footprint and taking longer to build. npm/yarn worked fine never knew what was causing it with pnpm.
I like pnpm but it does have its shortfalls due to its module linking and hoisting strategy. We've stuck with yarn for our monorepo, which also includes React Native projects and native node modules. I've tried to move to pnpm, but it's more hassle since you're forced to opt-out of the optimizations that it provides by changing the linking strategy, and so you might as well just use traditional NPM. For personal projects or JS/TS only repos, I've always use pnpm where possible.
You can enable regular npm linking strategy by adding `shamefully-hoist=true` to `.npmrc` file in your project root. You won't lose much by doing so: it still will be speedy and save you disk space.
@@Brawaru That assumes tools follow symlinks, which not all of them do unfortunately as they need to be resolved manually (e.g. using fs.readlink in NodeJS). This is especially a problem in React Native which relies on native builds of which there is currently no other solution than to use node-linker=hoisted with pnpm - in which case it's just like using npm and Yarn Classic. On top of that it adds more overhead, since you'd have to traverse the tree of files, then resolve any symlinks on the way, which is additional syscalls-this is especially noticeable on CI.
We got PNPM working with expo/RN, but then also in a monorepo where we had different modules of the app in separate projects. Plenty fun, wouldn’t do it again
I really enjoyed pnpm but I can't use it currently because next with output standalone (for Docker images) doesn't work with pnpm.. It copies symlinks to the output directory
so technical! he didn't explain shit, videos gets lazier and lazier, not even saying what's the difference between npm/yarn/pnpm anymore. He's just a fraud content-machine now.
It’s become my default, and have migrated some old projects, but it doesn’t work with everything. E.g I cannot get it to work with any nuxt 2 project. I should rather say that nuxt 2 won’t work with a pnpm node_modules folder.
Pnpm also reinstalls missing deps. With yarn I had to delete the node_modules folder when the Mozilla certs dep was gone for an obscure reason. Of course I only knew it was gone when my backend was running.. Pnpm is also smart enough to install/delete deps when you modify the package.json so you can get on with your life.
I used it for a while back, but with my most recent project and as dependencies size was vital I did a comparison between the 3 and yarn’s size was the lowest, so we just use yarn now
I use docker to bootstrap and run my projects. To get pnpm to work for me would take some additional steps to gain some of the benefits it describes. I don't think it'd be crazy but it's just not a priority for me quite yet.
Thank you for this video! I'm one of the oddities that uses yarn still. I've heard of PNPM, but never had any real reason to use it. I think I'll try it and see how it goes
Not sure if it's still the case, but I remember choosing Yarn's PnP implementation over pnpm because it had more strict enforcement of correct dependency usage. For me, tools that are more pedantic is a big selling point because it forces me to better understand them
I believe pnpm is stricter than yarn - it enforces explicitly specifying dependencies since they're nested vs yarn which allows you to use a dependency of a dependency due to the flat file structure
Being able to poke around in node_modules is really nice when debugging problems with external packages. I have isolated bugs inside third-party libraries, come up with fix on the spot, and have used my findings to file PRs (usually a few lines of code changes). Wondering if pnpm would make it more annoying to do this kind of thing.
generally speaking no, it will not be harder. You still have your node_modules folder but the files/folders are more or less symlinks. pnpm even has a native "patch-package" to patch broken dependencies, as far as I know
Pnpm's really great features: 1. no freeloading on some other package's dependency. 2. It supports package.yaml ! This allows me to comment my why the dependencies are there, or why specific versions are specified the way they are, and also it is much much easier to read. 3. no need for pnpm run x, if it is the name of a script just pnpm x. 4. Tacking on extra arguments to a script: `pnpm scriptname a b c` will tack a b c onto the end of the command line for the script. 5. Probably best-in-class workspace support.
PNPM just works. Using it for about a year now and it kicks absolute ass, especially in monorepo environments. Predictable, performant, overall impressive. I've had more issues with NPM on a day-to-day basis than I've had with PNPM in a last year.
At work, we went straight in to using pnpm for our monorepo (through the Rush toolchain) when Turborepo initially didn't support pnpm. It's great, but we're still waiting for proper symlink support in React Native/Expo so that we can maybe introduce our RN app to the monorepo (avoiding npm publishing/versioning some of our shared packages along the way).
I started using bun as my default bundler and runtime a while back. I hope non-hipsters also get to enjoy this speed and ease once it’s more established, because even pnpm and Vite seem chugging by comparison.
> I started using bun as my default bundler and runtime a while back @@cristianbilu he mentioned he's using Bun's bundler as well as his default bundler as well. but also Vite's not a bundler either, it uses esbuild & rollup internally
I'm a very strong supporter of pnpm. It's been excellent to me, and it does a lot more than just save space too. Although I will have to admit that I failed to understand how to make it's monorepo workspaces work
I love pnpm, the only issue is that it's still not compatible with Windows WSL2, which doesn't show hard links to Windows host, which kind of sucks if we work with Webstorm at the moment. So I stick to Yarn1 for now, hoping for a fix.
expo doesn't have a guide for setting up pnpm monorepo projects. It only has well documented yarn monorepo guide. That's why I am not very confident when thinking about t3 mobile stack's template for monorepo (it uses pnpm).
we have a monorepo with react17 and express backend and ive tried migrating. loads of small issues where i’ve just given up. issues with package resolution, react types all of a sudden being wrong and not having children anymore, msw bugging out. could be our subpar codebase, but it just works with yarn1. switching to pnpm is definitely on my wishlist but seeing how much stuff broke, i dont know if i can take the risk and defend the time spent migrating
Would be nice to see you try yarn (berry) too - lots of the same benefits, and no need for a separate file for workspaces - btw, yarn.lock pretty much looks like pnpm's lock file - yaml format
Sort of like a global node_modules for within your own repo or monorepo. It's smart enough to know not to duplicate dependencies that other dependencies depend on. I think.
@ cool, I've only used pnpm with bit cloud as that's what it uses to handle the dependencies for the project (now that I think about it its technically a monorepo, each component is it's own package).
what makes me to not use pnpm is bcz pnpm don't shown warning if I have a mismatch peer dependency issue when I do the pnpm install command. so I think it's really sucks., bcz maybe if I don't fix that issue immediately when I see the warning when install a package using pnpm add command and than two weeks later I forget about that issue bcz when I try to do pnpm install, the warning doesn't show
One issue I've found with relying on pnpm is in Windows the character length for directories has a set limit and so pnpm creates symlinks that break whenever you try to "sync" a project. I was using Google drive for a specific folder and when I switched over it caused much pain.
I have some issues with Yarn, some packages don't install but it does with npm, so I prefer use "a classic slow" but working thing, I'lll see how it goes with pnpm.
I'm loving it so much that I find it crazy that it took you so long! 😆 For real though... the first years weren't that great in my opinion. It had some performance problems (which were resolved pretty quickly though) and the creator wanted to keep the verbose npm terminal output. Fortunately, he obviously changed his mind. Blows my mind that you didn't mention that it uses symbolic links and that that's why it saves so much space and is so fast once stuff is in the cache. (Other package managers may do this as well now but pnpm pioneered it.) Also, I heavily disagree with not migrating to it for large corporate projects. ESPECIALLY there, it's awesome to be able to reduce those reinstall times on branch changes or whatever to a few seconds. (And maybe even speed up testing pipelines.)
pnpm is nice to use locally, but has been a pain to setup within containers like docker for me. I like npm and yarn because they are both preinstalled with the latest versions of node
I'd bet the pain @theuidawg3274 is referring to would be setting the global store. There's little benefit to using pnpm in these types of environments without first setting up some type of shared volume that's got a fast connection to the containers.
Pnpm is definitely faster than yarn and npm, and I like the experience when installing a new package with pnpm also reinstallation of packages is blazingly fast, I am using pnpm for a year
Last time I tried pnpm (been a few months), I had serious problems if I was using Prisma in the project because of how prisma generate works. I hope this has been fixed.
pnpm has a built-in dedupe command that actually works and doesn't just tell you that deduping "isn't needed". yarn-deduplicate existing at all shows that yarn's deduping doesn't work. Pnpm wins.
yes! pnpm is awesome, I'm using it has been a few years and never understand why no one uses it, it is always npm and yarn (I kinda understand npm for being the default, but today I don't see any difference between npm and yarn)
i have seen cross-platforms issues with pnpm which makes me just stick to yarn... the sentiment on twitter seems to be the same when i searched 'pnpm switch back yarn' which is why i havent touched it yet
npm and yarn don’t “probably work just fine” most of the time though. In my experience it’s common to deal with dependency issues where you need to delete your node_modules folder and other things. I’ve never had a single issue when using pnpm.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
0:49 NPM isn’t slow, it just gives you time to make a drink, have a shower, go for a run, get much needed 12hr sleep. It’s a feature for larger projects 😅
I've realised that slow NPM is usually from bad computer or slow internet - you're a brokie with wooden pc
@@aurelianspodarec2629 correct 👍 well done 👏
@@szmr I got two computers. One that is really old windows and a new windows. Same everything installs 15minutes on my old computer, and a few second to a minute on my new one. That's like 15x difference
@@aurelianspodarec2629 yeah fair play, I’ve got to connect to a work VPN which hampers my internet speed anyway
it's single-threaded, so only higher core clock speed would make a difference, and that is not easy to come by.
intel i9 14900K costs a fortune
@@aurelianspodarec2629
I like how React projects have so many dependencies that instead of solving that problem with common patterns and packages combined they decided to build a fast dependency installer.
😂😂
After trying Fresh for Deno and seeing that it only installs 300 files total for its deps (not packages, 300 TS files, and most of them are just Deno stdlib stuff) it kind of makes me never want to touch any Node/React stuff again lol
loooooooooooooool this is a gem comment
Well, it's arguably a good thing that there's so many packages as it's less work for 1 team and much more control over what you install. Of course it is slower though.
This is such a 2002 take
pnpm is goated for monorepos - Anything else results in you accidentally using dependencies installed in one package that aren't installed in another
this!
pnpm is great but it definitely needs more work in properly hoisting packages during builds, specifically on monorepos with web and mobile like nextjs and expo.
Yep!
I perfer to use pnpm when I can. But for projects with loads of dependencies, compatibility with pnpm have so far been kind of a pain in the ass, while yarn can handle those projects without any issue, albeit a bit slower.
Pnpm gave me issues when running 2 different open source projects. Not worth the hassle, I'm back to npm, maybe yarn.
You should have shown the node_modules folder! With pnpm all the sub dependencies hidden in a subfolder. So when you open node_modules you will just the dependencies defined in your package.json (plus a few extra folders)
Great future!!
I don't know why, but I tried it a while ago and for some reason, typing "pnpm" gave me some kind of keyboard dyslexia and I would always end up typing some other permutation of those letters. Lol.
yeah, I did need to add 'alias pn="pnpm"' to my rc file because of this lol
Dude, exactly.
@@bpuzoni That's genius. I'll have to do that.
Exactly, I was once working with someone who uses npm and I kept typing pnpm over and over again 😂
Relatable 🤣
Really glad that PNPM is catching on more and more. I made a pull request a few months ago to add PNPM support to replit/upm and I'm so glad I did that - just so that more people can be introduced to PNPM.
Conflicts in lockfiles is a huge issue. I am happy to hear in your case the pnpm lockfile had less conflicts than the alternatives. We did work a lot on minimising the amount of lockfile conflicts. Unfortunately, there is no way to completely avoid conflicts. We have some experimental settings for creating lockfiles with different names on branches. The idea is that once the branch is merged, a job merges the lockfiles and commits the updated "pnpm-lock.yaml" to the main branch, avoiding conflicts altogether.
Super weird to see pnpm succeeding. I started using it in 2018. I even filed an issue because it originally didn't work for AngularJS at all. I tried to get others in the company to start using it (i'm not a frontend dev, npm really just sucks when you have all the nice tools the backend has), but no one wanted to. It's great to finally see it succeeding. At my current company I think several teams are using it!
I definitely enjoy seeing the count of reused packages when I install a new package. Only problem is using npm for work and then accidentally doing npm i for a personal project then panic ctrl+c when I forget to use pnpm
antfu/ni solves this exact problem
@@_timestamp just installed this and I already love it, thank you
@@_timestamp you can also use only-allow
I use an alias so that I call npm as always, but use pnpm on the back
A colleague of mine told me about it a few years ago, and once I tried it I never looked back.
The biggest thing for me, that you didn't mention in this video, was workspaces! It makes setting up monorepos is super-easy.
We used pnpm in production on a monorepo and it caused all kinds of issues with dependencies, using incorrect versions and leading to high memory usage. We now swapped it for yarn again and all out issues disappeared.
We’re using in production for many monorepos successfully
Sounds like a developer problem rather than a pnpm problem
I'm using pnpm for a bunch of projects and monorepos in a company and it works fine.
@@daheck81 skill issue
dude, you frickin rock! i just had a seemingly unsolvable dependency issue in a prod application, saw this video, tried pnpm, and it just magically started working again. what a g!
Tysm Theo you trying it and sharing results saves many of us so much time 🙏
yarn lock is also yaml and human readable, and with yarn berry the install time is zero because you can commit gz and the yarn binary :D
Love PNPM, great to see it getting a light shined on. Have to still try out the monorepo feature. On it. Great channel thanks 🙏
Went back to yarn when nohoist didn't work in a monorepo with react native. Only reason I don't fully use pnpm rn.
Wowww!
This is the first time I've ever needed to slow down ⏬⏬⏬ a video instead of speeding it up ⏩⏩to 1.25x or 1.5x like I usually do. To be clear, I mean this as a compliment - your rapid-fire delivery packs so much valuable information into such a short time, all while maintaining perfect clarity. I'm impressed. Keep up the fantastic work!
This is amazing! Theo's video is serving as the HERO of the pnpm landing page!
pnpm scares me, we had a memory leak with a monorepo every time it recompiled it was creating a bigger memory footprint and taking longer to build. npm/yarn worked fine never knew what was causing it with pnpm.
I like pnpm but it does have its shortfalls due to its module linking and hoisting strategy. We've stuck with yarn for our monorepo, which also includes React Native projects and native node modules. I've tried to move to pnpm, but it's more hassle since you're forced to opt-out of the optimizations that it provides by changing the linking strategy, and so you might as well just use traditional NPM.
For personal projects or JS/TS only repos, I've always use pnpm where possible.
You can enable regular npm linking strategy by adding `shamefully-hoist=true` to `.npmrc` file in your project root. You won't lose much by doing so: it still will be speedy and save you disk space.
@@Brawaru That assumes tools follow symlinks, which not all of them do unfortunately as they need to be resolved manually (e.g. using fs.readlink in NodeJS).
This is especially a problem in React Native which relies on native builds of which there is currently no other solution than to use node-linker=hoisted with pnpm - in which case it's just like using npm and Yarn Classic.
On top of that it adds more overhead, since you'd have to traverse the tree of files, then resolve any symlinks on the way, which is additional syscalls-this is especially noticeable on CI.
Yup, it's time I get down with pnpm. Been putting it off for too long. Thanks for the video! I needed that push.
We got PNPM working with expo/RN, but then also in a monorepo where we had different modules of the app in separate projects. Plenty fun, wouldn’t do it again
The biggest advantage of pnpm is that it improves installation speed and saves huge storage space. I have been using it by default for four years.
symlink has been a hard issue with pnpm, esp on react native, i think everyone should give yarn v3 a try, it's on par in comparision with pnpm
I thought pnpm used hard links
I really enjoyed pnpm but I can't use it currently because next with output standalone (for Docker images) doesn't work with pnpm.. It copies symlinks to the output directory
is pnpm doesn't compatible with next js
?
no way sky is blue thanks theo wouldnt have guessed it, amazing technical video
so technical!
he didn't explain shit, videos gets lazier and lazier, not even saying what's the difference between npm/yarn/pnpm anymore.
He's just a fraud content-machine now.
pnpm rocks ❤
Thanks to one of your videos, I’m now using pnpm and it’s amazing!!!
It’s become my default, and have migrated some old projects, but it doesn’t work with everything. E.g I cannot get it to work with any nuxt 2 project. I should rather say that nuxt 2 won’t work with a pnpm node_modules folder.
Pnpm also reinstalls missing deps. With yarn I had to delete the node_modules folder when the Mozilla certs dep was gone for an obscure reason. Of course I only knew it was gone when my backend was running..
Pnpm is also smart enough to install/delete deps when you modify the package.json so you can get on with your life.
I used it for a while back, but with my most recent project and as dependencies size was vital I did a comparison between the 3 and yarn’s size was the lowest, so we just use yarn now
Yarn v3 is also fine. It also has node modules as linker which doesnt cause errors which pnp mode causes.
I use docker to bootstrap and run my projects. To get pnpm to work for me would take some additional steps to gain some of the benefits it describes. I don't think it'd be crazy but it's just not a priority for me quite yet.
Thank you for this video! I'm one of the oddities that uses yarn still. I've heard of PNPM, but never had any real reason to use it. I think I'll try it and see how it goes
Not sure if it's still the case, but I remember choosing Yarn's PnP implementation over pnpm because it had more strict enforcement of correct dependency usage.
For me, tools that are more pedantic is a big selling point because it forces me to better understand them
I believe pnpm is stricter than yarn - it enforces explicitly specifying dependencies since they're nested vs yarn which allows you to use a dependency of a dependency due to the flat file structure
pnpm is a necessity on smaller hard drives / ssds like on a laptop/macbook
Some might say, it was Godsend.
I went off to that "crazy world" of yarn 2 and its great
Being able to poke around in node_modules is really nice when debugging problems with external packages. I have isolated bugs inside third-party libraries, come up with fix on the spot, and have used my findings to file PRs (usually a few lines of code changes). Wondering if pnpm would make it more annoying to do this kind of thing.
generally speaking no, it will not be harder. You still have your node_modules folder but the files/folders are more or less symlinks.
pnpm even has a native "patch-package" to patch broken dependencies, as far as I know
I never knew the history, just started using pnpm about a year ago when I learned that it reuses dependencies. My hard drive has never been happier!
Pnpm's really great features: 1. no freeloading on some other package's dependency. 2. It supports package.yaml ! This allows me to comment my why the dependencies are there, or why specific versions are specified the way they are, and also it is much much easier to read. 3. no need for pnpm run x, if it is the name of a script just pnpm x. 4. Tacking on extra arguments to a script: `pnpm scriptname a b c` will tack a b c onto the end of the command line for the script. 5. Probably best-in-class workspace support.
PNPM just works. Using it for about a year now and it kicks absolute ass, especially in monorepo environments. Predictable, performant, overall impressive.
I've had more issues with NPM on a day-to-day basis than I've had with PNPM in a last year.
I just checked the node_modules size on my PC and it's 10G.
I was sceptical, but when pnpm saved me and my small 250ssd, boom! Amazing stuff!
Thanks for the video - pnpm seems to be solid tool to use in the future!
At work, we went straight in to using pnpm for our monorepo (through the Rush toolchain) when Turborepo initially didn't support pnpm. It's great, but we're still waiting for proper symlink support in React Native/Expo so that we can maybe introduce our RN app to the monorepo (avoiding npm publishing/versioning some of our shared packages along the way).
I started using bun as my default bundler and runtime a while back. I hope non-hipsters also get to enjoy this speed and ease once it’s more established, because even pnpm and Vite seem chugging by comparison.
I'm very hyped about Bun but it's too early for me to adopt
You realise Vite is not a dependency manager, right? It's a bundler
> I started using bun as my default bundler and runtime a while back
@@cristianbilu he mentioned he's using Bun's bundler as well as his default bundler as well.
but also Vite's not a bundler either, it uses esbuild & rollup internally
Wouhou!! Finally someone mentioned the beast
I hope you gave Yarn a try yet, because I really have great experience with it too.
I use both yarn and pnpm without preferring one above the other.
I'm a very strong supporter of pnpm. It's been excellent to me, and it does a lot more than just save space too. Although I will have to admit that I failed to understand how to make it's monorepo workspaces work
I love pnpm, the only issue is that it's still not compatible with Windows WSL2, which doesn't show hard links to Windows host, which kind of sucks if we work with Webstorm at the moment. So I stick to Yarn1 for now, hoping for a fix.
Yess, I also just switched to pnpm. Was worth it and does not take too much time
Been using pnpm since 2022! Love it.
Finally someone rises awareness around pnpm! Thanks for doing that! Maybe it will lead to e-waste reduction and a ton of saved time.
I just recently started using pnpm instead of yarn and npm some weeks ago and I love it.
expo doesn't have a guide for setting up pnpm monorepo projects. It only has well documented yarn monorepo guide. That's why I am not very confident when thinking about t3 mobile stack's template for monorepo (it uses pnpm).
we have a monorepo with react17 and express backend and ive tried migrating. loads of small issues where i’ve just given up. issues with package resolution, react types all of a sudden being wrong and not having children anymore, msw bugging out. could be our subpar codebase, but it just works with yarn1. switching to pnpm is definitely on my wishlist but seeing how much stuff broke, i dont know if i can take the risk and defend the time spent migrating
Would be nice to see you try yarn (berry) too - lots of the same benefits, and no need for a separate file for workspaces - btw, yarn.lock pretty much looks like pnpm's lock file - yaml format
Awesome, this video is already in the pnpm homepage
so in this case you would have a global node_modules handled by pnpm so you can reuse packages across all projects in your machine?
Exactly. It changed my life, now it's on all my personal projects
Sort of like a global node_modules for within your own repo or monorepo. It's smart enough to know not to duplicate dependencies that other dependencies depend on. I think.
@ cool, I've only used pnpm with bit cloud as that's what it uses to handle the dependencies for the project (now that I think about it its technically a monorepo, each component is it's own package).
For me, pnpm was a no-brainer once I learned about it. As a person with slow wifi, pnpm is a lifesaver 😂
You've convinced me, giving it a try now.
what makes me to not use pnpm is bcz pnpm don't shown warning if I have a mismatch peer dependency issue when I do the pnpm install command. so I think it's really sucks., bcz maybe if I don't fix that issue immediately when I see the warning when install a package using pnpm add command and than two weeks later I forget about that issue bcz when I try to do pnpm install, the warning doesn't show
One issue I've found with relying on pnpm is in Windows the character length for directories has a set limit and so pnpm creates symlinks that break whenever you try to "sync" a project. I was using Google drive for a specific folder and when I switched over it caused much pain.
Easy solution use a better os
File system is the biggest reason why I never look back to Windows after switching to MacOS
@@thienhuynh7962 the good part of Mac is it doesn’t get out of your way ironically you have access to a real Unix terminal
I am not into web development but is formatting your drive really necessary to clean your modules folder?? that seems very over the top
I have some issues with Yarn, some packages don't install but it does with npm, so I prefer use "a classic slow" but working thing, I'lll see how it goes with pnpm.
If I was spinning up a design system, would you recommend pnpm for that use case?
I got started with NPN, switched to Yarn, and in the past couple of years I've been using PNPM and never looked back
Pnpn install didn't cached well in my CI because of the way it use symlinks. Good tool thought was working fine locally.
what CI are you using?
Been using pnpm whenever I could, awesome thing
PNPM is supreme!
I'm loving it so much that I find it crazy that it took you so long! 😆
For real though... the first years weren't that great in my opinion. It had some performance problems (which were resolved pretty quickly though) and the creator wanted to keep the verbose npm terminal output. Fortunately, he obviously changed his mind.
Blows my mind that you didn't mention that it uses symbolic links and that that's why it saves so much space and is so fast once stuff is in the cache. (Other package managers may do this as well now but pnpm pioneered it.)
Also, I heavily disagree with not migrating to it for large corporate projects. ESPECIALLY there, it's awesome to be able to reduce those reinstall times on branch changes or whatever to a few seconds. (And maybe even speed up testing pipelines.)
I've been using pnpm for over a year now and have never looked back!
You give me Adam Scott vibes. Good content.
Love this content!
Is there `pnpm` for VS Code? It downloads each of the minor version for the plugins.
I too install all my dependencies in all the repos I've cloned several times a day completely from scratch
pnpm is nice to use locally, but has been a pain to setup within containers like docker for me. I like npm and yarn because they are both preinstalled with the latest versions of node
Just make a base image with pnpm installed
I'd bet the pain @theuidawg3274 is referring to would be setting the global store. There's little benefit to using pnpm in these types of environments without first setting up some type of shared volume that's got a fast connection to the containers.
That's the IT guy shirt you have over there, I got a shirt exactly like yours! :)
Pnpm is definitely faster than yarn and npm, and I like the experience when installing a new package with pnpm also reinstallation of packages is blazingly fast, I am using pnpm for a year
I still use npm, and I'm fine with that.
Can you talk about the Rush and pnpm?
Last time I tried pnpm (been a few months), I had serious problems if I was using Prisma in the project because of how prisma generate works. I hope this has been fixed.
This exactly. Npm just works. The grass always seems greener on the other side but at the end of the day, tech is just tradeoffs.
I’m looking for Bun which is releasing next month.
the first time I used pnpm I was on a slow connection and npm would fail and timeout pnpm on the other hand... less than a minute
I will definitely give it a shot
pnpm has a built-in dedupe command that actually works and doesn't just tell you that deduping "isn't needed". yarn-deduplicate existing at all shows that yarn's deduping doesn't work. Pnpm wins.
You have convinced me, Freddy Mercury
Underrated feature of using pnpm is that when copying `npm install some-package` you just type `p` then paste the rest.
yes! pnpm is awesome, I'm using it has been a few years and never understand why no one uses it, it is always npm and yarn (I kinda understand npm for being the default, but today I don't see any difference between npm and yarn)
The last time I tried pnpm it was a pain in the ass to get it working in our pipeline.
Node modules have filled up my space
Is pnpm actually good for every project? I haven't used it before and I noticed mixed opinions about it.
I tried yarn a few months ago having only use npm, and thought 'wtf, is this?'. The documentaiton was so hard to understand that I quickly bailed.
You finally changed to the industry standard 👋
For me, pnpm rejects to work on my machine
i have seen cross-platforms issues with pnpm which makes me just stick to yarn...
the sentiment on twitter seems to be the same when i searched 'pnpm switch back yarn'
which is why i havent touched it yet
there was like a repo that migrates their package manager to pnpm, only to switch back to yarn... sooo... kinda scared to use them
Does pnmp have own repository ?
Will npm still have motivation to proper mantain reposiotry if some else will get the cream and glory ?
how does it handle different versions of the same dependency?
npm and yarn don’t “probably work just fine” most of the time though. In my experience it’s common to deal with dependency issues where you need to delete your node_modules folder and other things. I’ve never had a single issue when using pnpm.
This video sold me to try it out