[HN Gopher] pnpm: Fast, disk space efficient package manager for...
___________________________________________________________________
pnpm: Fast, disk space efficient package manager for JavaScript
Author : modinfo
Score : 152 points
Date : 2022-04-05 14:31 UTC (8 hours ago)
(HTM) web link (pnpm.io)
(TXT) w3m dump (pnpm.io)
| synergy20 wrote:
| This is my default one, _much_ faster and disk space reduced
| dramatically when I have lots of node_modules in use. Can't
| recommend enough.
| eatonphil wrote:
| Were you coming from yarn or npm?
|
| I guess their benchmarks cover both [0]. But I'm also curious
| about independent figures.
|
| [0] https://pnpm.io/benchmarks
| synergy20 wrote:
| used to use npm, less often with yarn, now it's all pnpm
| eatonphil wrote:
| Gotcha. Yeah yarn has always been way faster to me than
| npm. And indeed in these benchmarks pnpm is much faster
| than npm and only slightly faster than yarn.
| sam_goody wrote:
| with its linking strategy, pnpm allows for multiple versions of
| the same package.
|
| I wish there was something like that in PHP's Composer, where I
| have repeatedly hit situations where different packages have a
| dependency that was pinned to a different version (such as one
| package using Guzzle 6 and another Guzzle 7), and therefore my
| composer.json was un-buildable.
|
| (I have less experience with NPM so I don't know if they have a
| different solution for this.)
| brunojppb wrote:
| I recently migrated a large project from yarn to pnpm and the
| speed difference is insane. Everything related to dependencies
| runs must faster during local development AND CI. T The only
| tricky thing is that we had some issues with some dependencies
| that could not work properly. But using the "---shamefully-hoist"
| flag did the trick. Everything works.
| eyelidlessness wrote:
| You can potentially solve this more narrowly with hoist-
| pattern[1] so you'll still benefit from the stricter structure
| overall. Or possibly even overrides[2] depending on the issue.
|
| 1: https://pnpm.io/npmrc#hoist-pattern
|
| 2: https://pnpm.io/package_json#pnpmoverrides
| rektide wrote:
| we're part way through switching all our monorepos from lerna to
| pnpm & simply could not be happier & more excited.
|
| lerna has soo many issues, is slow & cumbersome. #2142, no way to
| update dependecies in monorepo subprojects? how is there a
| monorepo tool where projects cant update their deps? everything
| on pnpm's built-in monorepo support just works, nice & easy &
| fast.
| rplnt wrote:
| Slightly unrelated, but it always amazes me how big the
| dependency tree in js world can get. Hundreds of megabytes for
| SPAs. I don't understand js development or how anyone can live
| with that, but since I do need to edit it here and there I
| stumbled upon this handy tool.
|
| https://github.com/voidcosmos/npkill
| zkochan wrote:
| It is unrelated because you don't have this issue with pnpm.
| pnpm uses a central content-addressable store and each unique
| file is written only once on a disk. It doesn't matter in how
| many projects you install the same dependency.
| AtlasBarfed wrote:
| "Fast": compared to what? What is "fast"?
|
| "Disk space efficient": again, compared to what?
|
| Javascript: ...oh
| forty wrote:
| If you have a pnpm monorepo, you need to know about
| https://pnpm.io/filtering#--filter-since which allows to run your
| test/lint/etc on only the packages that have been impacted by
| changes from master.
| andrew_ wrote:
| Love that this continues to be shared. One of the most exciting
| projects in the Node ecosystem.
| leerob wrote:
| We recently started sponsoring pnpm[1] as well as adding zero-
| config support for deployments and caching. I think pnpm is an
| incredible tool. Excited to see it grow further.
|
| [1]: https://vercel.com/changelog/projects-using-pnpm-can-now-
| be-...
| zkochan wrote:
| Thank you!
| steven-xu wrote:
| Summarizing the 3 major JS package management approaches:
|
| * Classic node_modules: Dependencies of dependencies that can't
| be satisfied by a shared hoisted version are nested as true
| copies (OSes may apply copy-on-write semantics on top of this,
| but from FS perspective, these are real files). Uses standard
| Node.js node_modules resolution [1].
|
| * pnpm: ~1 real copy of each dependency version, and packages use
| symlinks in node_modules to point to their deps. Also uses
| standard resolution. Requires some compatibility work for
| packages that wrongly refer to transitive dependencies or to peer
| dependencies.
|
| * pnp[2]: 1 real copy of each dependency version, but it's a zip
| file with Node.js and related ecosystem packages patched to read
| from zips and traverse dependency edges using a sort of import
| map. In addition to the compatibility work required from pnpm,
| this further requires compatibility work around the zip
| "filesystem" indirection.
|
| In our real-world codebase, where we've done a modest but not
| exhaustive amount of package deduplication, pnpm confers around a
| 30% disk utilization savings, and pnp around a 80% savings.
|
| Interestingly, the innovations on top of classic node_modules are
| so compelling that the package managers that originally
| implemented pnpm and pnp (pnpm and Yarn, respectively) have
| implemented each others' linking strategies as optional configs
| [3][4]. If MacOS had better FUSE ergonomics, I'd be counting down
| the days for another linking strategy based on that too.
|
| [1] - https://nodejs.org/api/modules.html#loading-from-
| node_module... [2] - https://yarnpkg.com/features/pnp [3] -
| https://github.com/pnpm/pnpm/issues/2902 [4] -
| https://github.com/yarnpkg/berry/pull/3338
| raydiatian wrote:
| That's kind of incredible that yarn pnp out performs pnpm. If
| that's generally true across most projects then I'm really glad
| that turborepo decided to use it for project subslicing.
| steven-xu wrote:
| The practical disk usage difference between pnp and pnpm
| appears to be almost entirely accounted for by the fact that
| pnp zips almost all packages. Both store ~1 version of each
| package-version on disk; it's just that one's zipped and
| one's not. The mapping entries for package edges in both
| cases (.pnp.cjs for pnp and the symlink farms for pnpm) are
| very small in comparison.
| lhorie wrote:
| Disk utilization is only one metric. The trade-off for Yarn
| PNP is that it incurs runtime startup cost. For us (~1000+
| package monorepo), that can be a few seconds, which can be a
| problem if you're doing things like CLI tools.
|
| Also, realistically, with a large enough repo, you will need
| to unplug things that mess w/ file watching or node-gyp/c++
| packages, so there is some amount of duplication and fiddling
| required.
| jbverschoor wrote:
| Problames long solved before, but problems that don't matter
| to the javascript crowd.. I think they actually love that
| things take so long. It makes them thing they're doing
| important work.. "We're compiling and initting"
| specialist wrote:
| > _1 real copy of each dependency version..._
|
| npm showed me that I lack creativity, for I could not imagine
| anything worse than maven.
|
| The ~/organization/project/release dir structure is the _ONE_
| detail maven got right. (This is the norm, the Obviously
| Correct Answer[tm], right?)
|
| And npm just did whatever. Duplicate copies of dependencies.
| Because reasons.
| fiddlerwoaroof wrote:
| Node is doing the right thing: if two dependencies in maven
| have conflicting dependencies, maven just picks an arbitrary
| one as _the_ version, which results in running with an
| untested version of your dependency (the dependency is
| actually depending on a version the developers of that
| dependency didn't specify). Because node allows the same
| dependency to be included multiple times, npm and friends can
| make sure that every dependency has the right version of its
| dependencies.
| CraigJPerry wrote:
| >> maven just picks an arbitrary one as _the_ version
|
| No that's never been the case. If you have conflicting
| versions of a dependency in your dependency graph, maven
| chooses the "nearest neighbour" version - it selects the
| version specified least far away from your project in the
| transitive dependencies graph.
|
| Pinning a particular choice is easy too - you just declare
| the dependency and specify the version you want instead of
| relying on transitive deps.
| fiddlerwoaroof wrote:
| This is what I mean by an arbitrary version: it's not
| determined by the dependency but by some characteristic
| of the dependency tree. And, this is only necessary
| because the JVM can't load two versions of the same
| dependency (ignoring tricks like the maven-shade-plugin)
| lhorie wrote:
| > Node is doing the right thing
|
| Node does a _different_ thing. It can coalesce two
| different versions into one if the two things are within a
| certain semver range, but there 's nothing that enforces
| whether things within a semver range are actually
| compatible. The most prominent example is Typescript, which
| famously does not follow semver. Another notable example of
| how NPM itself does things wrong is that it considers
| anything in the `^0.x` range as compatible, whereas semver
| distinctly says the 0.x range is "anything goes".
| fiddlerwoaroof wrote:
| I agree another the 0.x thing. The rest is basically a
| result of people refusing to use the versioning system
| the way it's designed to be used, which is a problem with
| a package not with the specified behavior of npm here:
| violating the rules of semver is UB
| lhorie wrote:
| I would definitely put part of the blame on the design of
| the system. It allows anyone to write stuff like
| `"lodash": "*"`, which is a perfectly valid range as far
| as semver goes. And then there's things like yarn
| resolutions, where a consumer can completely disregard
| what a library specifies as its dependencies and override
| that version with whatever version they want. And there's
| aliases (`"lodash": "npm:anotherpackage@whatever"`) and
| github shorthands and all sorts of other wonky obscure
| features. And we haven't even touched on supply chain
| vulns...
| [deleted]
| koolba wrote:
| Does this use symlinks to a single copy of each dependency?
| zkochan wrote:
| Not symlinks. Hard links. Or copy-on-write on systems that
| support them.
| jessaustin wrote:
| [EDIT: (thanks ttybird2! b^)] We might need to change the
| following diagram?
|
| https://pnpm.io/motivation
|
| It appears to show several symlinks? Thanks for pnpm!
| ttybird2 wrote:
| You are actually replying to the pnpm maintainer :p
| jessaustin wrote:
| A single copy of each required version of each dependency.
| koolba wrote:
| So is that a yes? Or does it still pull a copy for each
| projects local node_modules?
| jessaustin wrote:
| As you can see at the URL in sibling, pnpm maintains a
| private area where everything is stored. Everything in a
| local (or "global", really) node_modules tree is a link to
| the private store.
| tekkk wrote:
| I use pnpm only for monorepos for which I find it works quite
| well. Although at times there have been issues, mainly with
| symlinks getting messed up or linking to wrong dependencies.
| Well, mainly having multiple versions of same packages.
|
| But all in all I'm glad they are moving the JS/TS ecosystem
| forward and other managers are catching up to their innovations
| and likewise. Great monorepo support I feel is a big necessity
| for a manager and well-working symlinking to prevent the insane
| node_modules sizes.
| eyelidlessness wrote:
| I'm using PNPM in a side project to try it out. Overall, I like
| it. Yes, it does feel faster than Yarn (1, I gave up on Yarn 2
| pretty quickly when it wouldn't let me install a TypeScript beta
| even with PnP disabled). I've found its commands a little fussier
| to use than Yarn however.
|
| If I were to pick for a new project today, I'd probably go back
| to Yarn. But I'm glad there's PNPM as an option.
| CSDude wrote:
| It works very fast in CI, its cache is smaller and it builds
| node_modules much faster. I don't feel comfortable caching
| node_modules folder itself, because I got side effects even
| causing incidents before, not sure if its supposed to. Speed
| difference is 15s vs 35s for our use case which is pretty
| significant.
| zkochan wrote:
| pnpm is really good for monorepos and there are many big open
| source projects that use pnpm: https://pnpm.io/workspaces#usage-
| examples
| kall wrote:
| I'm pretty immune to most JS ecosystem churn, but on package
| managers I'm feeling it.
|
| All I want is a package manager that is correct, causes very few
| day to day issues and is going to work the same way for many
| years. Yet everyone seems to be optimizing disk usage and speed
| without even getting the basics (make it work, make it right)
| fully covered.
|
| I don't understand why people are optimizing for disk space at
| all tbh. Like, have you ever edited a video project, used docker,
| installed Xcode? I cannot imagine what you must be doing for all
| node_modules combined to take up more than maybe 100 GB on disk.
|
| pnpm seems to be the lightest of the bunch, which is nice but why
| even mess with symlinks and confuse other tools? Just put all the
| files in there, nest them and duplicate them and everything. I'll
| happily live with my 10 GB node_modules folder that never breaks
| and sometimes gives me a nice coffee break.
|
| Possibly I'm actually just salty that Metro doesn't support
| symlinks and would otherwise be on the pnpm love-train.
| ramesh31 wrote:
| NPM just has too much institutional inertia to avoid. The
| moment you make the decision to use something else, you are
| simply trading one set of warts for another. I can't even tell
| you how many projects I have seen waste countless hours of dev
| time on Yarn/NPM discrepancies. If you are working on anything
| with more than two people, you really need to just use the
| standard tooling that everyone is familiar with and that the
| entire ecosystem is based around. Anything else is yak shaving.
| draaglom wrote:
| I'm not sure if this is the _main_ reason, but one thing that
| makes node_modules size more than an aesthetic concern is
| serverless.
|
| Booting a serverless function with 100s of mbs of modules takes
| an appreciable time - to the point where some folks webpack
| bundle their serverless code
| [deleted]
| zkochan wrote:
| You can use pnpm without symlinks by setting node-
| linker=hoisted
|
| https://pnpm.io/npmrc#node-linker
| kall wrote:
| That's great news! pnpm might be my answer after all.
| ttybird2 wrote:
| Please note that pnpm is currently blocking all traffic from
| Russia and Belarus
| https://twitter.com/pnpmjs/status/1498306992577957890
| duxup wrote:
| "We will unblock it when you stop the war and de-occupy all the
| Ukrainian territory."
|
| There's what, maybe a handful of people who can make that
| happen?
| zkochan wrote:
| That was the deal a few weeks ago. After the atrocities that
| their army has committed in my country, I do not think I will
| ever unblock traffic from Russian Federation.
| jrochkind1 wrote:
| If that's how it works, there's a lot of people on the
| planet who have good reason to block traffic from the USA.
|
| Fortunately for me as a developer in the USA, I guess most
| of them, in the Global south, aren't developers, or know
| they can't be successful as developers blocking traffic
| from the USA, no matter how many atrocities the US military
| or intelligence have committed in their countries. :(. I
| guess if they wanted to try, it's an interesting question
| if that would be some kind of effective action in changing
| US atrocious behavior. Probably not. :(
|
| That said, this is basically a form of boycott. There does
| seem to have been some significant change of opinion around
| the value and ethics of the tool, from when the main
| example we had was the BDS movement called by Palestinian
| civil society against Israel. (Which by the way, does _not_
| in fact call for doing things like blocking all network
| access to those in Israel, what people are doing against
| Russia is way broader and less targetted than what the...
| more controversial(?) Palestinian-led BDS has done or
| called for against Israel. Which is interesting.)
| zkochan wrote:
| In the USA there are different people. Good and bad.
| There are states that are very conservative and there is
| California. There are some basic values that everyone
| agrees upon. I think nobody can claim that everyone is
| bad or good in the US. Same goes for any other democratic
| society. Same goes for Ukraine. There are a lot of people
| that I don't like in Ukraine.
|
| In Russia there are some good people but they are in
| extreme minority. Extreme. Even the liberals in Russia
| are supporting the annexation of Crimea. Maybe the
| dictatorship is the reason, maybe the propaganda. I don't
| know and I don't care. This is how it is and I do what I
| can to exclude them from my life.
| ttybird2 wrote:
| Oh, I thought that you were Hungarian (after reading https:
| //github.com/pnpm/pnpm/issues/1080#issuecomment-373872...),
| but I guess you are both? Your reaction makes more sense in
| that case. Although I do hope that you will reconsider the
| idea of a permanent block, I believe that open source (and
| the world in general) would be much worse and divides
| between nations would be greater if Greek software blocked
| Turkey, Israeli software blocked Germany, middle eastern
| software blocked the US, etc.
| hbn wrote:
| I'm sure Putin is reeling that he can't use an obscure
| package manager for his web projects
| hirako2000 wrote:
| the idea is to anger the citizens so that they then turn
| their anger against Putin. it doesn't matter that Putin is
| not directly impacted.
|
| I fundamentally disagree with the blockade. this moves
| makes this project incompatible with open source licensing.
|
| if anyone is interested in this sub thread, it diverge from
| the discussion around the tool itself, but note that all
| the project standing for Ukraine in this manner are: -
| breaking one of the fundamental principle of open source -
| pretty risky to use. what if your locality also becomes
| block-listed. - demonstrates a poor judgment from their
| authors, who more often than not are reluctant to
| debate/reconsider their position.
|
| Reactions to extreme circumstances can understandably be
| emotional, it doesn't imply that logical criticisms are
| necessarily insensitive.
| afavour wrote:
| Russian TV is wall to wall coverage about their highly
| successful campaign to eradicate Ukrainian Nazis. An action
| like this might at least be a small hint to everyday Russians
| that things aren't as they appear.
| leshenka wrote:
| "error 1020" is not a very descriptive thing and I bet that
| a regular person would just think the site is broken
| triyambakam wrote:
| And then they suggest that Russian users use a VPN to get
| through. I don't understand this line of thinking at all.
| dane-pgp wrote:
| If Russians get used to using VPNs, they might have more
| opportunity to check independent news sources and see how the
| war is going, and what people in other countries think.
|
| Ironically, blocking Russian IP addresses could be seen as a
| form of non-violent protest against Russian web censorship.
|
| https://en.wikipedia.org/wiki/List_of_websites_blocked_in_Ru.
| ..
| zkochan wrote:
| Slava Ukrayini!
| webknjaz wrote:
| Geroiam Slava!
| laurent123456 wrote:
| It seems the main maintainer is from Ukraine so I can see how
| he got there. https://github.com/zkochan
| [deleted]
| keb_ wrote:
| pnpm is great. I love `pnpm store prune`. Also it's great for
| monorepos, check out https://github.com/panoply/mithril-demo for
| an example.
| rauttis wrote:
| I recently migrated a fairly large monorepo (20+ packages) that
| used Lerna and npm to pnpm, and the improvement in developer
| experience was pretty massive.
|
| Dependency install times went down by a huge amount, and all the
| strange issues we had with lerna and npm sometimes erroring out,
| requiring us to remove all node_modules folders and re-install
| everything, are just gone.
|
| We even noticed that the size of some of our production bundles
| went down. Before some dependencies that were used in multiple
| packages were being duplicated in our webpack bundles needlessly,
| but the way pnpm symlinks dependencies instead of duplicating
| them fixed that as well.
|
| The non-flat node_modules structure did break some things as
| well, since in some places we had imports pointing to packages
| that were transitive dependencies and not defined in
| package.json. I see this as a positive though, since all those
| cases were just bugs waiting to happen.
| krikou wrote:
| I experienced the same. The overall dev experience /
| responsiveness of pakage management makes it very unlikely I
| would like to go back to npm ever.
| Chyzwar wrote:
| We migrated from pnpm to yarn3 with node_modules linker. pnpm
| focus on wrong things, speed, disk efficiently is less important
| than stable, reproducible, and developer experience of yarn3.
| physicsguy wrote:
| We did exactly the same, tried to uneject from CRA recently and
| just could not get it to work in PNPM, switched to Yarn and it
| just worked.
| xiphias2 wrote:
| As a person who uses npm just for some hobby coding projects,
| it's quite frustrating that there are new partly incompatible
| package managers for the javascript ecosystem: npm, pnpm, yarn,
| yarn 2.
|
| Some packages need one, some another, so I tried to switch to
| yarn (or yarn 2) for a package that I wanted to try out, but then
| other packages stopped working.
|
| If there are clearly better algorithms, why not refactor npm and
| add them in experimental flags to npm and then setting them to
| default as they mature (with safe switching from one data
| structure or another)?
| arcatek wrote:
| > If there are clearly better algorithms, why not refactor npm
| and add them in experimental flags to npm
|
| While node_modules has many flaws, in the current ecosystem all
| modes have their own pros and cons, and there isn't a "clearly
| better" algorithm: node_modules has less friction, PnP is
| sounder, and pnpm's symlinks attempt to be kind of an in-
| between, offering half the benefits at half the "cost".
|
| Like in many computer science things, it's tradeoffs all the
| way. Part of why Yarn implements all three.
| zkochan wrote:
| pnpm also implements all three: https://pnpm.io/feature-
| comparison
|
| But I think it is best to use Yarn for PnP and pnpm for the
| symlinked node_modules structure.
| vosper wrote:
| Generally I've found sticking with npm to be best. It's not the
| super-slow thing that it was before, and I can't remember the
| last time a package didn't install because it wasn't compatible
| with npm.
|
| I tried pnpm and it didn't just work, so I gave up. I would
| revisit it, but npm works.
|
| These days I don't really see a reason to use yarn (but would
| like to hear them).
| lelandfe wrote:
| Yarn's workspaces provide some cool benefits to monorepos
| which AFAIK npm hasn't matched. You can get there with Lerna
| + npm, though.
| citrons wrote:
| I have so far had very good npm workspace experience. Just
| define "workspaces" property in package.json and your off.
| https://docs.npmjs.com/cli/v8/using-npm/workspaces
|
| Right now only pain-point with npm is that "npm link" can't
| be forced to install peer dependencies so I'm unable to
| easily test typesscript built libraries within other
| projects.
| trulyme wrote:
| Given what a dumpster fire npm ecosystem is security wise, it's
| best to run the whole build chain in a container anyway, at
| least for frontend apps. This way you also don't care about the
| chosen package manager or node.js version - you can just set it
| as you wish in the Dockerfile. It does take more disk space
| though, but to me it's a nice compromise.
| 5e92cb50239222b wrote:
| Containers don't provide much protection from malware, unless
| you're running it rootless under an unprivileged user (no
| sudo access, no ssh keys or anything else interesting in the
| home directory, etc; and even then it's limited because the
| attack surface is enormous).
| trulyme wrote:
| I mean, of course? Especially, why would I put ssh keys and
| similar in the container?
|
| This still doesn't mean that one can install just any
| package, but it does make it much more difficult for it to
| do much harm. Breaking out of a container is not as trivial
| as it once was. That said, it is not a perfect solution, so
| I'd be happy to hear of better ones. Any suggestions?
| gizzlon wrote:
| gVisor, VMs
| Cu3PO42 wrote:
| For what it's worth Yarn 3 implements essentially all modes. It
| can do standard node_modules, its own Plug'n'Play, as well as
| pnpm-style hardlinking to a global cache.
|
| Edit: I just learned from another comment that PNPM also
| supports Plug'N'Play :) Thanks steven-xu!
| zkochan wrote:
| pnpm as well supports all three modes. But I think it is
| better to use Yarn for the PnP mode and pnpm for the
| symlinked mode.
|
| Here is a feature comparison: https://pnpm.io/feature-
| comparison
| xiphias2 wrote:
| So it should just be backported to npm to show that the
| authors are serious about backwards compatibility.
| zkochan wrote:
| Both pnpm and Yarn are independent projects maintained by
| the community. I personally think that these are better
| projects than npm CLI because they can make their own
| decisions. Not decisions dictated by business needs of a
| company.
|
| I was OK to merge pnpm into npm in the past. They have
| never suggested me this opportunity. Instead, they decided
| to re-implement pnpm's algorithm into npm and call it
| "isolated mode".
| xiphias2 wrote:
| I see, I tried it now, it looks great.
|
| Most of my problems were created by the material UI
| libraries (I wanted to use them with SvelteKit), but I
| just got rid of it as those libraries were making
| development harder instead of helping.
|
| I still wish there would be a nice UI library for Svelte,
| but I guess that's the disadvantage of not going with the
| mainstream frontend toolkit.
| sph wrote:
| That's literally xkcd #927: let's make a standard that
| encompasses all previous standards, what can go wrong?
|
| Now you have to maintain three different code paths, two of
| which depend on the behaviour of external projects, so you're
| always playing catch up.
|
| That's such a bad idea on so many levels.
| hu3 wrote:
| Is there any gotcha if I switch from npm to pnpm?
|
| And can I use pnpm when working in a team where other devs use
| npm?
| scambier wrote:
| pnpm uses its own lock file (pnpm-lock.yaml), while npm uses
| package-lock.json
|
| You definitely should use the same manager (npm, yarn, pnpm,
| whatever) as your teammates' or you're going to run into
| problems, either with them or with your CI workflow.
| hu3 wrote:
| thanks!
| inglor wrote:
| note: You can use `pnpm import` for converting a
| lockfile.json to a pnpm-lock.yaml
|
| https://pnpm.io/cli/import
|
| (This is not an endorsement of or recommendation of pnpm
| which I personally don't use daily)
| jakubmazanec wrote:
| Pnpm doesn't auto install peer dependencies, which is annoying
| and forces you to unnecessary add them to package.json. Npm@7
| (and newer) with auto install of peer deps is much easier to
| use in this regard.
| ricardobeat wrote:
| Isn't that exactly how it's supposed to be? If you're
| installing a package that has peer dependencies, you should
| already depend on them. Otherwise they are not "peer
| dependencies" anymore, just a normal dependency with a
| version range.
|
| The whole peer dependencies story is another clusterfuck.
| Everyone simply ignored the invalid peer dependency warnings,
| and now npm itself will just install all of them in 'whatever
| works' version. To get real peer dependency resolution you
| need a --strict-peer-deps flag. Not exactly a "feature" in my
| book.
| Wronnay wrote:
| Yeah - this peer dependency thing always makes issues, when
| I try to upgrade a big Ionic project...
|
| Peer dependencies added more problems than they solved in
| my eyes... Most peer dependencies warnings come because
| some maintainer forgot to update the package.json and not
| really because two packages don't work with each other...
| eyelidlessness wrote:
| The point of peer dependencies is to allow users more
| flexibility in choosing the specific version of the
| dependency. It's not intended to specify any kind of
| conflict between the packages, it's effectively BYO sub-
| dependency.
| jrochkind1 wrote:
| regular traditional dependencies can already be specified
| as a range, yes? Any range the specifier wants (and can
| legitimately work with), yes?
|
| What is it about peer dependencies that give the host
| more flexibility in choosing the specific version?
|
| Real question, not a challenge! I really don't understand
| this stuff, I've always found javascript dependency
| management very confusing.
| jakubmazanec wrote:
| I want to specify only those deps that I use directly.
| Imagine a `foobar` package, that has `babel` peer
| dependency because it does some transpiling or whatever.
| For me as a user of `foobar`, that Babel requirement could
| have been regular dependency instead of peer. I don't care,
| I don't use Babel. In another words - if a package manager
| has all the information necessary to install all
| dependencies, why should I add another, redundant
| information to my package.json?
| jrochkind1 wrote:
| I am so confused about the purpose of a "peer dependency"
| in the first place then.
| jakubmazanec wrote:
| You can read here why the peer deps were introduced:
| https://nodejs.org/es/blog/npm/peer-dependencies/
|
| Imagine this structure of packages: your-
| app/ +-- dep-a/ | +-- dep-c +-- dep-b
| +-- peer-dep
|
| Very simplified: `dep-c` is dependency of `dep-a`, so it
| is installed in its node_modules, but `peer-dep` is peer
| dependency of `dep-a`, so it is in node_modules of `your-
| app`. `dep-b` could also define `peer-dep` as its peer
| dependency, so it is installed only once. When npm
| switched to flat node_modules structure, peer deps become
| somewhat redundant, but not quite. Pnpm, which uses
| symlinks to achieve proper node_modules structure while
| avoiding long filenames, combined with auto install of
| peer deps would be ideal package manager.
| jimmy2020 wrote:
| I've migrated from yarn to pnpm two days ago and I can tell the
| difference when I first hit install. I am working on a workspace
| so I have multiple packages with nested dependencies. For this
| case, I thought yarn (the classic version) is the ideal solution
| that was until I discovered pnpm. Thanks to its non-flat
| algorithm the packages have clean dependencies. Previously in
| yarn if you install `foo` in any package you can reuse it later
| in the workspace even if it's not listed in the package
| dependency. With pnpm it's not the case, which means a clean
| dependency tree and serving the purpose of what's workspace is
| meant for. If you want to share the dependency you can install it
| in the root which makes sense to me. Another big advantage is the
| recursive/parallel command something I couldn't do without Lerna.
| And it's fast. install once and it's there in the disk, so if you
| manage multiple projects, dependency installation is not
| something you wait for it's just there.
| yewenjie wrote:
| pnpm is awesome except when it does not work - which happens very
| rarely but it is a nightmare to debug. For all the other times,
| it is way faster and lightweight than npm.
| scambier wrote:
| I was unable to use pnpm with a project that used Electron (~2
| years ago), IIRC because some spawned process was incompatible
| with symlinks. It's the only time it caused me trouble though,
| it's indeed much faster than npm. I'd love to use it at work
| too.
| zkochan wrote:
| In any cases where pnpm doesn't work, you may set the node-
| linker=hoisted option and it will work:
|
| https://pnpm.io/npmrc#node-linker
|
| With node-linker=hoisted, pnpm creates a traditional hoisted
| (aka flat) node_modules, without using symlinks.
| PeledYuval wrote:
| pnpm has been my goto JS monorepo package manager + script runner
| for a couple of years now. IMO it has almost zero downsides and
| huge upsides. I'd be surprised if npm doesn't end up adopting the
| pnpm node_modules directory hierarchy in the next 5 years or so.
| no_wizard wrote:
| I believe the RFC for just that has landed:
|
| https://github.com/npm/rfcs/blob/main/accepted/0042-isolated...
|
| Yarn has a PNPM mode now too:
|
| https://dev.to/arcanis/yarn-31-corepack-esm-pnpm-optional-pa...
___________________________________________________________________
(page generated 2022-04-05 23:00 UTC)