Thanks for the video, your pnpm install was not fresh (first run), it seems like you have already run it before and haven't cleared the store. You can see at 12:57, pnpm reused 1667 packages, and downloaded 0. No way it would download that many packages in 11seconds.
The title and opening lines made me skeptical at first but I am glad I watched until the end! Turned out a very useful and well delivered video. Thank you!
Loving pnpm so far. Going to start learning more about it and specifically "Workspaces". I have had no use for Workspaces to this point, but I am about to take off on a new project that is a perfect use case for Workspaces and all of pnpm's features.
You can hide node_modules folder in /.vscode/settings.json file. Also, if you open any file in this folder, only this file will be shown in the file tree.
So just when I was almost sold and tried going to the pnpm site to check it out, I found out that the creator blocks all access from Russia (note: I do not support war). Guess I'll be sticking with good old npm.
Good video. In the last example, it would have been good to compare the node_modules folder size between the three package managers as well. It is great that it is faster, but sometimes the size of the node_modules is an issue. It would be interesting to see how much of a space reduction PNPM achieves with the symlinking.
@@thekwoka4707 yes exactly. He covered this in the video. Rather than copying the same dependencies, they are symlinked which saves disk I/O (hence the performance boost) and space.
the explanation makes no sense, how does it solve the problem of having multiple copies of the same package with different versions, the symlinking thing only changes how packages can be accessed.
Also I want to add after trying pnpm I would like to say that it's not actually that good at all it's slower than npm A LOT slower. But I do like the whole global node modules concept that part is really cool to me
I once saw pnpm used by a dude on youtube, and I was like "what the heck is pnpm?", so I searched about it, tried it, and fell in love with it. It's almost a year now since I switched to pnpm😉 And I'm loving it🤘
The last benchmark seems a bit off to me. Npm and yarn were executed without lock files and pnpm was executed with the lock file present, based on what I can see the file tree.
And think that they use this video on the home page of the pnpm website 😁. I mean it's still very fast, but keep it real, not with cutting corners to make it look faster than it is.
@@_checkit Yeah, but pnpm is not just about the performance it's about space saving too. If you have a lot of projects made with npm/yarn, try to run npkill it's a tool that shows how much space you are using with all the node_modules directories you have!
For such projects you may set the node-linke=hoisted setting for pnpm (via .npmrc). It will create a "classic" node_modules but you still get other benefits of pnpm, like speed and disk space efficiency.
@@zkochan does this work for react, next and expo projects ? Cause I really think pnpm is super cool, but it's painful inability to work on more complex installs is a big deal breaker.
@@0jinx it works with everything. If there are issues, you can set "shamefully-hoist=true" and run "pnpm install". If there are still issues, you set "node-linker=hoisted", remove node_modules and run "pnpm install".
That is probably some misunderstanding. By security he probably means that the app code has only access to dependencies that are added as dependencies to package.json. So your package will not break when installed as a dependency.
So pnpm doesn’t have a flat node_modules directory but instead has an equivalent flat .pnpm directory? Just use the latest Yarn (it has different options which you need to research). There is no need for a complicated directory tree structure and symlinking when you can keep the dependency tree information in a file.
I never switched to Yarn, and I most likely will never switch to this. Yarn was an optimization, this is an optimization, and neither of these should have been a new package manager - they should have been a PR against the existing package manager. This is a clear case of throwing away the baby with the bath water. And you come out with benchmarks - and yeah, the benchmarks look great, and it's really the only thing anybody talks about when they push for these alternative package managers. But a package manager is so much more than just "npm install", and it gets us into so many edge cases and problems with these tools. And don't get me started about splitting the ecosystem, the inconsistent tooling, the added learning curve and confusion and complexity, the time people will waste bikeshedding over the best package manager, and on and on. These tools are just an optimization, and if these changes are really reliable, if they're really any good, they should have shipped these as features/changes to the original package manager. For all the time you people waste debating which package manager is the best, learning new commands (which have arbitrarily been renamed and changed for no other reason besides developers being opinionated) trying to solve incompatibilities, teaching and learning and pushing your benchmark nonsense, yeah, this saves you a little time over "npm install", which you've likely more than paid back already with all the mess and complexity you add for yourselves and anyone who has to work with you or tries to contribute to your projects. These tools shouldn't exist. And you care about all the wrong things. 😒
Great opinion, lil bit over though. It's actually annoying when something just goes wrong when you have to co-op with others - which will sure happen, and you have to dig through the whole internet, read through all the comments to find a solution, and then sitting there gets mad. I'm actually a pnpm user, and it's really fantastic, but yes I do agree with you.
I kind of agree... but the world is not black and white like this. Sometimes it takes the learning of one project to apply to another. Sometimes it's easier to start from fresh, than change the original. Sometimes people do not agree and they create their own forks. It will always happen so long as we have a rich and diverse opensource ecosystem. The best case scenario in this example is that NPM contributors can see the progression of tools like Yarn and pnpm and use this to improve their own. As a developer using these tools, it's a win win and you have the freedom to choose whatever suits your needs best.
I guess I disagree a tiny bit on this one. Although I totally agree on the arbitrary renaming of commands (that's super stupid)... PNPM is a fundamentally different approach in how to store dependencies when compared to NPM. The rework required to change NPM to this new approach would not only be much more than "just a pr", it would be a huge undertaking to make it backwards compatible. This is probably the number 1 reason NPM wouldn't adopt something like this. So the developers of PNPM have few choices, fork or create another alternative. While I don't like change for the sake of change, I believe there will always be evolution, and this is definitely an evolutionary step in my opinion.
When working with large monorepo (turborepo, nx etc) that got many apps fully loaded with TS & Storybook $ ESList etc and multiple team members, npm just doesn't seem to cut it (too large of a space&time complexity). Altho I agree that having different names for commands (as yarn does) for the sake of it isn't nice, pnpm has the same names as npm so it's quite intuitive in that regard. In the end tho, it's all project specific. When working with micro services where each service has it's own repo, the simplicity & availability benefits of npm become brighter. So it's up to each of us what's right for our projects, it's always better to have options, isn't?
Sorry, pnpm is using the npm cache. So you cleared the cache out to begin with, let npm spend time downloading the libraries, and then pnpm just symlinked them. I'm sure you didn't mean to, but the result is not a legit test result. Also, at about second 0:43 you peekaboo a benchmark where pnpm is not faster, but we don't get to see what that was :(
I'm not interested in PNPM because of "fast downloads", but more because of preserving space on my laptop's SSD when I'm on the go (It's a MacBook, yes, I know... I know....) Also, you can actually install PNPM with NPM itself nowdays.
For such projects you may set the node-linke=hoisted setting for pnpm (via .npmrc). It will create a "classic" node_modules but you still get other benefits of pnpm, like speed and disk space efficiency.
If you speak about yarn, do you speak about yarn 1 or yarn 3 and if yarn 3, have you tried the different modes? Has yarn 3 the same performance with the pnpm mode as pnpm itself?
Interesting, I just tested it on a big project, but it wouldn't compile using PNPM, I switched back to YARN, and everything works again. I also found it to be way slower than YARN for some reason. I guess it's not perfect as it may cause issues in some edge cases. I'll try it against later on smaller projects; it will probably work just fine on these.
When pnpm doesn't work, you can always use it with the node-linker=hoisted setting. In that case it will create a "classic" node_modules without using symlinks.
I already knew pnpm, it sound great, but never used it because I kept asking if it's so great why isn't anyone using it? There's any compatibility problem or workaround necessary?
There is no downside. If there are some issues with the symlinked node_modules, you can also switch to "classic" node_modules with the node-linker=hoisted setting.
I got a question about the peer dependency issue that in the last example installs all the necessary dependencies, but is it that simple to just install those missed packages? Or I might expect other issues after installation?
With pnpm, is it possible to have 1 node_modules folder in ur computer and all the local projects direct to it instead of each project having its own node_modules because they share the same 90% of the files there as other projects? T
no, you will have multiple node_modules but the files in each of that node_modules will be not copies of files but clones (or hard links) of files from a single content addressable store. So, the same file will not be written twice to the disk
I think we have some responsibility as developers to not embrace any new technology that emerge any single day just because it seems faster? cooler? or what ever. I found this particular behavior really common in JS community, and it's making a mess in the ecosystem. Also, I seriously doubt of anyone that only tells me the pros of something but not the cons.
I appreciate your answer, but personally i disagree with you. I'm David a midterm frontend developer form Hungary. I started using pnpm 26th of April. for a quick try I converted one of my oldest projects with pnpm to test is it actually works, and tried to add several dependencies which never worked together in npm (but yarn solved the problems for me). And I tried out to see if it solved the npm's problems. It did, but I have to mention i had to install several specific versions. I think it is a very powerful alternative, and i think in CS you shouldn't judge any new, because i think those bring the whole industry forward. But I'm not here to argue, just wanted to say my opinion.
I fail to understand why people bother so much about npm vs yarn vs pnpm vs dadada?! How much time do we spend in our development effort installing or updating dependencies? Is all this discussion really worth it? I have serious reservations of the cost vs benefit of this. Any thoughts? I am open to your opinion 😄 I guess the benefit would come not from performance but any security benefits or maybe better organisation and less bugs. Is there any significant gain in these goals?
We have a couple of projects that requires compilation of heavy libraries. Every time there is a yarn install (yarn v1), it's recompiling the deps which can be very slow depending on your computer. So instead of losing focus by waiting, getting stuff installed in a couple of seconds, by for example symlinking already compiled deps, can make a notable difference in productivity and developer experience. I'd rather see npm improved though.
This is absolutely typical for the JS community. Shiny new thing that starts out fast for certain usecases, but never gets to compete with the old boys properly. Then it adds new features that mean you have projects that *require* using this rather than one of the others. And is it just me or does it look like npm is actually a LOT faster for a number of common usecases, including the ones we care most about? I do update more often than I do install...
I would love to use pnmp. However we use WSL2 at work and windows doesn’t support simlink folders. This makes it hard for ides like webstorm to crawl and find the dependencies.
the javascript package landscape is an insane mess, just copy NUGET, also prevent packages from being deleted off npm, it really frustrating when you trying to find the git repo of some deleted package
no, you should not switch as soon as possible if dependency install waiting time becomes a problem it is probably a problem with your dependencies, that you don't really need, not with package manager i dont say that pnpm is a bad choice- just that pnpm is NOT the best choice for EVERY project tools like npm and yarn are way more mature. i personally just tried pnpm in random project that i was working on some time ago and yes, instllation time was way faster (the procedure i used was installing dependencies once, then deleting all dependencies, then measuring time of execution for both yarn and pnpm), in my test case it was 7s for pnpm and 25 for yarn but i was no longer able to build the project using single command (without changes to package.json). why? because my build scripts looks like this ``` "prebuild": "rimraf dist", "build": "nest build", "prebuild:prod": "yarn build", "build:prod": "yarn pkg --public --compress GZip -t node17-linuxstatic dist/main.js -o out", ``` and pnpm can't understand pre and post scripts. i think it is a thing worth mentioning. also, i tried to use lifecycle hooks. according to pnpm docs, the only lifecycle hook is pnpm:devPreinstall. but the, suddenly my postinstall script got executed. why isn't it documented? there is a page in pnpm wiki named "feature comparision", which mentions functions that other package managers have, but pnpm don't (and vice versa). if you want to convince somebody why should he switch package manager i think it is the place to start from pnpm looks very promising, but for now i decide to wait for it to be more widely used- right now i cannot be sure that there won't be any issues that will eventually slow me down during development, instead of making it faster. edit: also, i don't see command like yarn upgrade-interactive --latest implemented in pnpm, just pnpm outdated and this may be very annoying
"pnpm import" is only needed if you already have a lockfile from yarn or npm and you want to generate a pnpm lockfile using information from package-lock.json or yarn.lock.
diversity in JS is good and bad thing at the same time... While offers a ton of libs to make our lives better , disorientate (new) devs with a lot package managers , we should move on , and make deprecated old package managers , proven not good in performance in core of their arch..
Solved: Remove some script from angular cli. For some reason some scripts broke and some packages where not install by default on pnpm install Bro I uninstall the my yarn packages and I still it with pnpm, and it doesn't work. An unhandled exception occurred: Script file node_modules/marked/marked.min.js does not exist. See "/private/var/folders/kb/5w49qrc551z1chsj_x4fhz1r0000gn/T/ng-SCa1hV/angular-errors.log" for further details.
I would like to appreciate the help provided by the Creator of PNPM @Zoltan Kochan
Does not work in my country
how to install missing peer dependencies? pnpm config set auto-install-peers true
Thanks for the video, your pnpm install was not fresh (first run), it seems like you have already run it before and haven't cleared the store. You can see at 12:57, pnpm reused 1667 packages, and downloaded 0. No way it would download that many packages in 11seconds.
The title and opening lines made me skeptical at first but I am glad I watched until the end! Turned out a very useful and well delivered video. Thank you!
Loving pnpm so far. Going to start learning more about it and specifically "Workspaces". I have had no use for Workspaces to this point, but I am about to take off on a new project that is a perfect use case for Workspaces and all of pnpm's features.
what i really care the most is the minified folder structure...
it happens so often for VScode to open my node_modules and and endless scroll >_
You can hide node_modules folder in /.vscode/settings.json file. Also, if you open any file in this folder, only this file will be shown in the file tree.
@@pavelzinchenko952 thankyou , kind sir
Yep, for me too
@@pavelzinchenko952 thank you.
Just press Ctrl/Cmd + 0 and then hold ArrowLeft
Mindblowing! Thanks for the visibility! I'll go with pnpm!
So just when I was almost sold and tried going to the pnpm site to check it out, I found out that the creator blocks all access from Russia (note: I do not support war).
Guess I'll be sticking with good old npm.
Gladly it doesn't wipe out the whole hard drive by replacing all files with hearts ... :\
Good video. In the last example, it would have been good to compare the node_modules folder size between the three package managers as well. It is great that it is faster, but sometimes the size of the node_modules is an issue. It would be interesting to see how much of a space reduction PNPM achieves with the symlinking.
The symlinking is only more space beneficial as you have multiple projects using the same dependencies.
@@thekwoka4707 yes exactly. He covered this in the video. Rather than copying the same dependencies, they are symlinked which saves disk I/O (hence the performance boost) and space.
Wow, did'nt know it existed. Thank you for this awesome video. You earned a subscriber today
the explanation makes no sense, how does it solve the problem of having multiple copies of the same package with different versions, the symlinking thing only changes how packages can be accessed.
By using a content addressable store. All files are hard linked (or cloned) to node_modules from a single place on the disk.
It doesn't solve the one of different versions. But it does mean you don't need a bunch of the same version.
I have no preferences over package managers, npm is builtin and I use that, I don't spend my day doing npm installs to see how u save 10 seconds.
@@Juan.Irizar but it was 2 minutes saved..???
Also I want to add after trying pnpm I would like to say that it's not actually that good at all it's slower than npm A LOT slower.
But I do like the whole global node modules concept that part is really cool to me
Great overview!
Thank you James!
I once saw pnpm used by a dude on youtube, and I was like "what the heck is pnpm?", so I searched about it, tried it, and fell in love with it.
It's almost a year now since I switched to pnpm😉 And I'm loving it🤘
The last benchmark seems a bit off to me. Npm and yarn were executed without lock files and pnpm was executed with the lock file present, based on what I can see the file tree.
You're part of the 1%! Those who go beyond the headline.
And think that they use this video on the home page of the pnpm website 😁. I mean it's still very fast, but keep it real, not with cutting corners to make it look faster than it is.
@@_checkit Yeah, but pnpm is not just about the performance it's about space saving too. If you have a lot of projects made with npm/yarn, try to run npkill it's a tool that shows how much space you are using with all the node_modules directories you have!
Wow....I need to make the change.
Seems life changing ✨
I'm a pnpm user but I've encountered many bugs and problems with it. Small projects? Sure, but I'd stick to yarn for the bigger ones.
pnpm is cool but there are many projects that have issues with it like Nuxt.
For such projects you may set the node-linke=hoisted setting for pnpm (via .npmrc). It will create a "classic" node_modules but you still get other benefits of pnpm, like speed and disk space efficiency.
@@zkochan does this work for react, next and expo projects ? Cause I really think pnpm is super cool, but it's painful inability to work on more complex installs is a big deal breaker.
@@0jinx it works with everything. If there are issues, you can set "shamefully-hoist=true" and run "pnpm install". If there are still issues, you set "node-linker=hoisted", remove node_modules and run "pnpm install".
@@zkochan thx for this info
Wowww.. ITS amazing bro🎉
That's amazing thank you, I thought "oh noo yet another thing to change" but you convinced me that It's kinda must to change with this features
I tried it:
npm install express: 2,804s
pnpm add express: 2,752s
It's not really faster.
Thanks for exposing this. But there’s not a lot of explanation of what it solves. “It solves security issues”. Which ones? And how?
That is probably some misunderstanding. By security he probably means that the app code has only access to dependencies that are added as dependencies to package.json. So your package will not break when installed as a dependency.
So pnpm doesn’t have a flat node_modules directory but instead has an equivalent flat .pnpm directory? Just use the latest Yarn (it has different options which you need to research). There is no need for a complicated directory tree structure and symlinking when you can keep the dependency tree information in a file.
PNPM has great package aliasing/overrides and have built in node version control.
Using hard links instead of copying doesn't matter when you have btrfs 😎
Thanks for the video ! what type of microphone are you using? sounds great
Cool, I think it is time for me to finally switch from npm to something new and it will be pnpm. Thanks!
Interesting, but Yarn v2+ does not use node_modules at all
Think Yarn v3 does something similar
Okay! I gonna switch to PNPM tomorrow.
I never switched to Yarn, and I most likely will never switch to this. Yarn was an optimization, this is an optimization, and neither of these should have been a new package manager - they should have been a PR against the existing package manager. This is a clear case of throwing away the baby with the bath water. And you come out with benchmarks - and yeah, the benchmarks look great, and it's really the only thing anybody talks about when they push for these alternative package managers. But a package manager is so much more than just "npm install", and it gets us into so many edge cases and problems with these tools. And don't get me started about splitting the ecosystem, the inconsistent tooling, the added learning curve and confusion and complexity, the time people will waste bikeshedding over the best package manager, and on and on. These tools are just an optimization, and if these changes are really reliable, if they're really any good, they should have shipped these as features/changes to the original package manager. For all the time you people waste debating which package manager is the best, learning new commands (which have arbitrarily been renamed and changed for no other reason besides developers being opinionated) trying to solve incompatibilities, teaching and learning and pushing your benchmark nonsense, yeah, this saves you a little time over "npm install", which you've likely more than paid back already with all the mess and complexity you add for yourselves and anyone who has to work with you or tries to contribute to your projects. These tools shouldn't exist. And you care about all the wrong things. 😒
Great opinion, lil bit over though.
It's actually annoying when something just goes wrong when you have to co-op with others - which will sure happen, and you have to dig through the whole internet, read through all the comments to find a solution, and then sitting there gets mad.
I'm actually a pnpm user, and it's really fantastic, but yes I do agree with you.
I kind of agree... but the world is not black and white like this. Sometimes it takes the learning of one project to apply to another. Sometimes it's easier to start from fresh, than change the original. Sometimes people do not agree and they create their own forks. It will always happen so long as we have a rich and diverse opensource ecosystem. The best case scenario in this example is that NPM contributors can see the progression of tools like Yarn and pnpm and use this to improve their own. As a developer using these tools, it's a win win and you have the freedom to choose whatever suits your needs best.
I guess I disagree a tiny bit on this one. Although I totally agree on the arbitrary renaming of commands (that's super stupid)...
PNPM is a fundamentally different approach in how to store dependencies when compared to NPM. The rework required to change NPM to this new approach would not only be much more than "just a pr", it would be a huge undertaking to make it backwards compatible. This is probably the number 1 reason NPM wouldn't adopt something like this. So the developers of PNPM have few choices, fork or create another alternative.
While I don't like change for the sake of change, I believe there will always be evolution, and this is definitely an evolutionary step in my opinion.
npm gives you too many errors and also it's also makes the project heavy
pnpm solves it, so why not we switch to this?
When working with large monorepo (turborepo, nx etc) that got many apps fully loaded with TS & Storybook $ ESList etc and multiple team members, npm just doesn't seem to cut it (too large of a space&time complexity). Altho I agree that having different names for commands (as yarn does) for the sake of it isn't nice, pnpm has the same names as npm so it's quite intuitive in that regard. In the end tho, it's all project specific. When working with micro services where each service has it's own repo, the simplicity & availability benefits of npm become brighter.
So it's up to each of us what's right for our projects, it's always better to have options, isn't?
Best so far
These tools are getting better and better
I think it's not taking yarn berry (v2+) into account which kindof revolutionazes package manager approach in node stack
Yep at 11:29 you can see he's still using yarn 1, not the new yarn versions
because this is a staged video.. he removed the lock files for npm and yarn during the install.
@@ahmedifhaam7266what lockfiles have to do with it?
neato. using pnpm. you've convinced me. also using vite this year. development has never been so fast...
Sorry, pnpm is using the npm cache. So you cleared the cache out to begin with, let npm spend time downloading the libraries, and then pnpm just symlinked them. I'm sure you didn't mean to, but the result is not a legit test result. Also, at about second 0:43 you peekaboo a benchmark where pnpm is not faster, but we don't get to see what that was :(
I'm not interested in PNPM because of "fast downloads", but more because of preserving space on my laptop's SSD when I'm on the go (It's a MacBook, yes, I know... I know....)
Also, you can actually install PNPM with NPM itself nowdays.
I was surprised to see my React Shopping Cart in the example, thank you man :D
Thanks for making it open-source
surprised you didnt switch to pnpm XD, this was a staged video btw.
can you do a comparison of it with yarn V2? I heard yarn V2 does not use node_modules? sorry. newbie here.
Thank you!
I really like the concept, but I had some problems with it before. Bugs that are absent in npm and yarn.
For such projects you may set the node-linke=hoisted setting for pnpm (via .npmrc). It will create a "classic" node_modules but you still get other benefits of pnpm, like speed and disk space efficiency.
If you speak about yarn, do you speak about yarn 1 or yarn 3 and if yarn 3, have you tried the different modes? Has yarn 3 the same performance with the pnpm mode as pnpm itself?
time command is not working. can you please guide me how to run/install command with time prefix
It would have been helpful to see how you solved the missing peers :(.
Well, I tried using it on an ionic angular project and pnpm import reports success, without creating a node_modules folder or whatsoever
Interesting, I just tested it on a big project, but it wouldn't compile using PNPM, I switched back to YARN, and everything works again.
I also found it to be way slower than YARN for some reason.
I guess it's not perfect as it may cause issues in some edge cases.
I'll try it against later on smaller projects; it will probably work just fine on these.
Weird. Was your project perhaps using node v10 or v12 and were you trying that with pnpm v7? pnpm v7 only works on node 14 and older for example
@@hiagooliveira6510 I'm on Node 16.14.2. and yes pnpm v7.
When pnpm doesn't work, you can always use it with the node-linker=hoisted setting. In that case it will create a "classic" node_modules without using symlinks.
Why does PNPM add Express as a dependency of Express? "it allows express to import itself" this makes absolutely 0 sense to me. Who can enlighten me?
I wonder why comparing it with npm? under the hood they (yarn or pnpm or any other package managers) resolves packages from npm registry. isn't it?
Wow...you helped me save 3 souls!!!!!!
I already knew pnpm, it sound great, but never used it because I kept asking if it's so great why isn't anyone using it? There's any compatibility problem or workaround necessary?
just use npm, the speed is about the same, this video is staged.. yarn v2 is nice too.
1.8s think of it as 1 second. 10.44 nah its 11. problem? :D Nice video but you could be more objective.
What is the downside of pnpm?
There is no downside. If there are some issues with the symlinked node_modules, you can also switch to "classic" node_modules with the node-linker=hoisted setting.
Is that the hated one?
I got a question about the peer dependency issue that in the last example installs all the necessary dependencies, but is it that simple to just install those missed packages? Or I might expect other issues after installation?
With pnpm, is it possible to have 1 node_modules folder in ur computer and all the local projects direct to it instead of each project having its own node_modules because they share the same 90% of the files there as other projects?
T
no, you will have multiple node_modules but the files in each of that node_modules will be not copies of files but clones (or hard links) of files from a single content addressable store. So, the same file will not be written twice to the disk
it's not python.
Inaccurate comparison. pnpm had missing peer dependencies while yarn took care of them.
Yep. Dude missed an opportunity to actually measure anything
but pnpm does not compatible with react-native :(
I think we have some responsibility as developers to not embrace any new technology that emerge any single day just because it seems faster? cooler? or what ever. I found this particular behavior really common in JS community, and it's making a mess in the ecosystem. Also, I seriously doubt of anyone that only tells me the pros of something but not the cons.
I appreciate your answer, but personally i disagree with you. I'm David a midterm frontend developer form Hungary. I started using pnpm 26th of April. for a quick try I converted one of my oldest projects with pnpm to test is it actually works, and tried to add several dependencies which never worked together in npm (but yarn solved the problems for me). And I tried out to see if it solved the npm's problems. It did, but I have to mention i had to install several specific versions. I think it is a very powerful alternative, and i think in CS you shouldn't judge any new, because i think those bring the whole industry forward. But I'm not here to argue, just wanted to say my opinion.
@@streamekispi594 köszi
I fail to understand why people bother so much about npm vs yarn vs pnpm vs dadada?! How much time do we spend in our development effort installing or updating dependencies? Is all this discussion really worth it? I have serious reservations of the cost vs benefit of this. Any thoughts? I am open to your opinion 😄
I guess the benefit would come not from performance but any security benefits or maybe better organisation and less bugs. Is there any significant gain in these goals?
We have a couple of projects that requires compilation of heavy libraries. Every time there is a yarn install (yarn v1), it's recompiling the deps which can be very slow depending on your computer. So instead of losing focus by waiting, getting stuff installed in a couple of seconds, by for example symlinking already compiled deps, can make a notable difference in productivity and developer experience. I'd rather see npm improved though.
I hate how in JS there seems always to be an awesome new thing that you absolutely have to glue in your increasingly disparate toolset
This is absolutely typical for the JS community. Shiny new thing that starts out fast for certain usecases, but never gets to compete with the old boys properly. Then it adds new features that mean you have projects that *require* using this rather than one of the others.
And is it just me or does it look like npm is actually a LOT faster for a number of common usecases, including the ones we care most about? I do update more often than I do install...
I would love to use pnmp. However we use WSL2 at work and windows doesn’t support simlink folders. This makes it hard for ides like webstorm to crawl and find the dependencies.
On systems that don't support symlinks pnpm uses junctions. Also, you may use pnpm without symlinks/junctions by setting node-linker=hoisted.
Are you sure symbolic links don't work in windows or you are talking something specific about WSL2?
You can still use pnpm it's officially supported
the javascript package landscape is an insane mess, just copy NUGET, also prevent packages from being deleted off npm, it really frustrating when you trying to find the git repo of some deleted package
what about patch-package compatibility?
Doesnt npm do this now?
no, you should not switch as soon as possible
if dependency install waiting time becomes a problem it is probably a problem with your dependencies, that you don't really need, not with package manager
i dont say that pnpm is a bad choice- just that pnpm is NOT the best choice for EVERY project
tools like npm and yarn are way more mature. i personally just tried pnpm in random project that i was working on some time ago
and yes, instllation time was way faster (the procedure i used was installing dependencies once, then deleting all dependencies, then measuring time of execution for both yarn and pnpm), in my test case it was 7s for pnpm and 25 for yarn
but i was no longer able to build the project using single command (without changes to package.json). why?
because my build scripts looks like this
```
"prebuild": "rimraf dist",
"build": "nest build",
"prebuild:prod": "yarn build",
"build:prod": "yarn pkg --public --compress GZip -t node17-linuxstatic dist/main.js -o out",
```
and pnpm can't understand pre and post scripts. i think it is a thing worth mentioning.
also, i tried to use lifecycle hooks. according to pnpm docs, the only lifecycle hook is pnpm:devPreinstall. but the, suddenly my postinstall script got executed. why isn't it documented?
there is a page in pnpm wiki named "feature comparision", which mentions functions that other package managers have, but pnpm don't (and vice versa). if you want to convince somebody why should he switch package manager i think it is the place to start from
pnpm looks very promising, but for now i decide to wait for it to be more widely used- right now i cannot be sure that there won't be any issues that will eventually slow me down during development, instead of making it faster.
edit: also, i don't see command like yarn upgrade-interactive --latest implemented in pnpm, just pnpm outdated and this may be very annoying
god that was fast!
Why do `pnpm imort` instead of just install?
"pnpm import" is only needed if you already have a lockfile from yarn or npm and you want to generate a pnpm lockfile using information from package-lock.json or yarn.lock.
It didn't take 1 second. It took 1.8 seconds......
Nice try buddy but I'm not changing my package manager again.
Does anyone have the link for the git repository of the shop website he used in the example?
There you go: github.com/jeffersonRibeiro/react-shopping-cart
Ahh honestly it depends from project to project… I’d never pigeonhole myself into one over the other.
On switching to pnpm, we would miss the cool loading spinner that npm had
I like yarn's progress bar 😀
@@CoderOne Intresting. But pnpm doesn't have it. Progress bar of pmpm looks lame
I like using pnpm... I dunno... seems fine to me.
Does it work with AWS Code Artifact?
Yes. But if it doesn't support symlinks, you'll have to use the node-linker=hoisted setting.
Problem is the dependencies
Tried using pnpm on a vue app recently and it failed. yarn worked fine.
you know i ussualy use the install time to go grab a coffe
but yarn has a cute logo...
NPM workspace is less buggy than PNPM.
Although I know it is not PNPM but the libraries to blame.
1.85 second - yeah took one second lol
more overhead to save couple of seconds
Npm doesn't support Ukrane. Interesting
bummer
this dude is saying pnpm is fast but it's still slow for my slow-ass laptop and wifi 😂
One extra letter to type? Madness
alias npm=pnpm
diversity in JS is good and bad thing at the same time... While offers a ton of libs to make our lives better , disorientate (new) devs with a lot package managers , we should move on , and make deprecated old package managers , proven not good in performance in core of their arch..
checkout newer npm 8 its superfast
no
Bruh wtf another one!!!
Pass
Solved: Remove some script from angular cli. For some reason some scripts broke and some packages where not install by default on pnpm install
Bro I uninstall the my yarn packages and I still it with pnpm, and it doesn't work. An unhandled exception occurred: Script file node_modules/marked/marked.min.js does not exist.
See "/private/var/folders/kb/5w49qrc551z1chsj_x4fhz1r0000gn/T/ng-SCa1hV/angular-errors.log" for further details.
according to Fast installation npm > yarn > Pnpm > BUN. 😇🐣 ( bun takes shortest time to install things)