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.
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 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.
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)
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.
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.
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
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!
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.
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.
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.
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
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.
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
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.
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
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 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
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.
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
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 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.
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
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
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).
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
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.
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 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've saw enough people having problems with pnpm so I'm avoiding it atm. Npm has been flawless for me, programming is stressful enough, I want my tools to disappear, not bring new problems.
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 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.
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.
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).
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.
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.
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.
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).
It's just how every other language's dependency management has worked for decades. Everything in JavaScript seems to start from ignorance and proceed back to the norm.
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
As someone who has just picked up programming and has just started getting these types of videos recommended, i am a little embarrassed to admit that I got about half way through before realizing that you weren't talking about physical package deliveries. I clicked on this thinking that there might be a better app/website to manage and track my amazon packages.
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.
Nah pnpm is awesome even if you only have a few repos. Reinstalling when new packages are added or they’re updated is made so much faster and easier. The only issue is having to nuke packages when bugs arise, but that hasn’t been too bad yet
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.
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 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 🤣
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!!
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
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.
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
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!
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
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!
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.
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.
Went back to yarn when nohoist didn't work in a monorepo with react native. Only reason I don't fully use pnpm rn.
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.
Yarn v3 is also fine. It also has node modules as linker which doesnt cause errors which pnp mode causes.
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.
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
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.
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
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
Tysm Theo you trying it and sharing results saves many of us so much time 🙏
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.
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
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 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
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.
Love PNPM, great to see it getting a light shined on. Have to still try out the monorepo feature. On it. Great channel thanks 🙏
This is amazing! Theo's video is serving as the HERO of the pnpm landing page!
pnpm rocks ❤
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
Finally someone rises awareness around pnpm! Thanks for doing that! Maybe it will lead to e-waste reduction and a ton of saved time.
Yup, it's time I get down with pnpm. Been putting it off for too long. Thanks for the video! I needed that push.
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 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.
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!
I was sceptical, but when pnpm saved me and my small 250ssd, boom! Amazing stuff!
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
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
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).
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
Yess, I also just switched to pnpm. Was worth it and does not take too much time
Thanks to one of your videos, I’m now using pnpm and it’s amazing!!!
For me, pnpm was a no-brainer once I learned about it. As a person with slow wifi, pnpm is a lifesaver 😂
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
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.
I got started with NPN, switched to Yarn, and in the past couple of years I've been using PNPM and never looked back
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 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've saw enough people having problems with pnpm so I'm avoiding it atm. Npm has been flawless for me, programming is stressful enough, I want my tools to disappear, not bring new problems.
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 just recently started using pnpm instead of yarn and npm some weeks ago and I love it.
I still use npm, and I'm fine with that.
Been using pnpm since 2022! Love it.
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.
Thanks for the video - pnpm seems to be solid tool to use in the future!
Awesome, this video is already in the pnpm homepage
You've convinced me, giving it a try now.
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
You give me Adam Scott vibes. Good content.
Been using pnpm whenever I could, awesome thing
Wouhou!! Finally someone mentioned the beast
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.
I've been using pnpm for over a year now and have never looked back!
If I was spinning up a design system, would you recommend pnpm for that use case?
You finally changed to the industry standard 👋
I don't know why node_modules meme is popular instead of Rust's dependencies which is so much larger than node_modules
That's the IT guy shirt you have over there, I got a shirt exactly like yours! :)
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).
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.
For me, pnpm rejects to work on my machine
I'm ok with any of the three, but if I had to pick one it'd be pnpm > yarn > npm
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
You have convinced me, Freddy Mercury
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.
Yep, I use pnpm with all my fullstack web apps, including those with prisma.
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.
PNPM is supreme!
I am just waiting for bun 1.0 to outperform everything
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).
It's just how every other language's dependency management has worked for decades. Everything in JavaScript seems to start from ignorance and proceed back to the norm.
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
lol - Company laptop with only two projects on it. I think I have over 60 projects on my work computer from just the last 5 years. 😂
You're working in a web agency and not a product company
@@mrleblanc Nope - it's a big fortune 50 company. My team supports a bunch of internal products for our engineering organization.
Theo finally touching some grass ❤
The last time I tried pnpm it was a pain in the ass to get it working in our pipeline.
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.
Node modules have filled up my space
I will definitely give it a shot
I haven't had a lock conflict in a while. I think yarn fixes it for you now
Now we just have to wait for Bun to be the next thing after pnpm 😂
As someone who has just picked up programming and has just started getting these types of videos recommended, i am a little embarrassed to admit that I got about half way through before realizing that you weren't talking about physical package deliveries. I clicked on this thinking that there might be a better app/website to manage and track my amazon packages.
I just checked the node_modules size on my PC and it's 10G.
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.
People complaining about node modules have obviously never seen the rust target directories.
Nah pnpm is awesome even if you only have a few repos. Reinstalling when new packages are added or they’re updated is made so much faster and easier. The only issue is having to nuke packages when bugs arise, but that hasn’t been too bad yet
Love this content!