6 ms·

Yarn v2 PnP is simply a lifesaver if you have a medium+ sized monorepo. We have a monorepo with 180 packages here. Without pnp, it takes 1h+ just to npm instal

Yarn v2 PnP is simply a lifesaver if you have a medium+ sized monorepo. We have a monorepo with 180 packages here. Without pnp, it takes 1h+ just to npm install any new third party package in any local package, it’s a joke. With pnp it takes 18s. So yes, from my point of view NPM is completely inadequate for any serious JS codebase.

georgyo 6y ago
Cannot figure out why you are being down voted. YarnV1 and NPM are horrible if you have a large dependency tree. YarnV2 was the first time I enjoyed the package manager.
- 411111111111111 6y ago
  Likely because he indirectly said that projects using less then 180 dependencies aren't serious.
  - romanoderoma 6y ago
    could it be that in some languages (like my language for example) serious is kinda of a synonym for large? I've been downvoted at times for using it to mean exactly that, but I can't help it after more than 40 years of thinking in a language different from English.
  - crubier 6y ago
    By serious I meant large indeed, I’m not a native speaker. I have some serious projects that have less than 180 packages too aha. But if you start an ambitious company with a JS codebase today, start with yarn v2, you’ll save yourself some pain in the future.
benologist 6y ago
This NPM cache been a huge time-saver for me, you can run it locally or across your whole network for a shared cache - https://guides.sonatype.com/repo3/quick-start-guides/proxying-maven-and-npm/ https://guides.sonatype.com/repo3/quick-start-guides/proxyin... https://hub.docker.com/r/sonatype/nexus/ https://hub.docker.com/r/sonatype/nexus/
cute_boi 6y ago
I don't know why you are down voted but I agree here. PNP is so good it takes less time less storage. Yarn v2 is very superior than yarn v1/npm
deleted 6y ago
[deleted]
eyelidlessness 6y ago
I tried yarn 2 on a greenfield project, but discovered: - pnp is made possible in part by mysterious “patches” to certain dependencies that don’t work well with it. Mysterious as in they’re obfuscated, and there isn’t much detail besides commit history. This is blocking if you wanna try out, say, the TypeScript 4.1 beta and the patch isn’t ready yet. But more importantly um... I do not want my dependency manager mysteriously patching stuff with obfuscated code????? - it applies these patches even if you disable pnp, so same objections to the entire yarn 2 approach (currently) So I’m back on yarn 1 and apparently gonna need to look at npm 7 at this point.
- eyelidlessness 6y ago
  I wrote the above before caffeine really kicked in, so I neglected to add: pnp is itself achieved in part by obfuscating your entire dependency tree. That takes a loooot of trust, on a matter where trust has already exceedingly deteriorated. In hindsight, I regret even considering it.
  - acemarke 6y ago
    Can you clarify what you mean by "obfuscating the dependency tree"?
    - desert_boi 6y ago
      They probably mean the idea that once you're in PnP, you can "kind of, sort of" peer into zipfs deps, but not in the same way that was possible in bare node_modules. That said, I think yarn 2's PnP + zero installs (https://yarnpkg.com/features/zero-installs https://yarnpkg.com/features/zero-installs) is lovely with CI. Instead of tacking 40+ seconds to resolve deps every build, vending deps with PnP on is much cheaper than the node_modules equivalent.
    - eyelidlessness 6y ago
      A gigantic single file encoded version of `node_modules` is just modules I can’t go look in.
untog 6y ago
I'd push back against "serious JS codebase", there. Maybe it's just me but a monorepo with 180 packages sounds like a hole you've dug yourself into and you're propping yourself up with yarn. I certainly don't think that anyone who keeps their packages separate (you could do that even within a monorepo, surely) has a "non-serious" codebase.
- crubier 6y ago
  Well yarn exists for this purpose so I guess I’m not the only one doing this. And if the alternative involves having to manage independent versioning of 180 packages and their inter-dependencies then no thanks. I’m not saying the situation is completely perfect (yarn v2 had its rough edges in the beginning for example), but it’s not too bad either. This monorepo is the best organized codebase of this size and diversity I’ve ever seen. Feel free to explain alternative methods to manage 180 packages with 7 developers while sleeping at night.
croes 6y ago
Some would say the same about NodeJS especially since Deno exists.
lhorie 6y ago
We have a pretty large monorepo codebase (460 packages and counting) that we're migrating from yarn v1 to yarn v2. I'll say it's definitely not a plug-n-play migration (pardon the pun). Some issues we ran into: - it can be difficult to reason about the layout of peer dependencies. Often times libraries that rely on Symbols or referential equality break and you need to mess with packageExtensions or add resolutions or unplug. Debugging mostly consists of throwing stuff at a wall and see what sticks - file watching at large enough projects breaks w/ file descriptor exhaustion errors, forcing you to find and unplug the offending libraries - there's a number of known incompatible libraries (flow being one of the most prominent) and the core team approach to these at this point follows paretto (20% effort for 80% results, e.g. special casing for typescript), meaning I don't believe there will ever be a 100% compatibility milestone w/ the ecosystem - it's much more black-boxy in terms of day-to-day debugging (e.g. it's much harder to manually edit files in node_modules to trace some root cause) - we ran into inscrutable errors deep in packages that interface w/ C++ and basically were only able to fix by pinning to an earlier version of a library that did not depend on said package. - migration cost is heavily proportional to codebase complexity. My understanding is that Facebook gave up on it completely for the foreseeable future and ours has similarly been a significant time investment (and we're not even targeting strict mode yet) The pros: - install times and project switching times are indeed fast, even in our codebase that contains multiple major versions of various packages - yarn v2 has many interesting features, such as protocols (though it's debatable if you want to commit to lock-in to benefit from those)
- acemarke 6y ago
  From what I've seen, the "unplug" command is supposed to allow you the ability to temporarily unzip a package so that you can do the traditional "hand-edit a file in a dependency" debugging approach.
  - lhorie 6y ago
    Yes, but when you're dealing w/ transitive dependencies, often times you need to jump between many packages. And you then need to clean up after your debugging since you typically don't want to leave things unplugged if they don't need to be (as that affects performance). I'm not saying it's impossible to debug, just that you end up having to jump through more hoops.
madjam002 6y ago
Yarn 2 is very nice. The portal: protocol is great and it works well with Nix package manager.
vosper 6y ago
Did you try out pnpm, by chance? I’ve read a few good things, but it doesn’t seem to get mentioned all that often. So I’m curious what people with larger projects think about it. https://pnpm.js.org/ https://pnpm.js.org/
- andrew_ 6y ago
  I use it in some rather large repos and am a very big fan. It's simply fantastic for every type of repo and project I've thrown it into.
- crubier 6y ago
  I did try it but it caused two problems as compared to yarn v2: the dependency resolution algorithm seems less deterministic or strict, causing version incompatibilities that yarn v2 did solve, and also the symlinks are poorly supported by many tools (nextJS until very recently, react native etc...). Also the install is longer with pnpm. However it has less runtime performance impact.

georgyo 6y ago

Cannot figure out why you are being down voted. YarnV1 and NPM are horrible if you have a large dependency tree. YarnV2 was the first time I enjoyed the package manager.

411111111111111 6y ago
Likely because he indirectly said that projects using less then 180 dependencies aren't serious.
- romanoderoma 6y ago
  could it be that in some languages (like my language for example) serious is kinda of a synonym for large? I've been downvoted at times for using it to mean exactly that, but I can't help it after more than 40 years of thinking in a language different from English.
- crubier 6y ago
  By serious I meant large indeed, I’m not a native speaker. I have some serious projects that have less than 180 packages too aha. But if you start an ambitious company with a JS codebase today, start with yarn v2, you’ll save yourself some pain in the future.

benologist 6y ago

This NPM cache been a huge time-saver for me, you can run it locally or across your whole network for a shared cache - https://guides.sonatype.com/repo3/quick-start-guides/proxying-maven-and-npm/ https://guides.sonatype.com/repo3/quick-start-guides/proxyin... https://hub.docker.com/r/sonatype/nexus/ https://hub.docker.com/r/sonatype/nexus/

cute_boi 6y ago

I don't know why you are down voted but I agree here. PNP is so good it takes less time less storage. Yarn v2 is very superior than yarn v1/npm

deleted 6y ago

[deleted]

eyelidlessness 6y ago

I tried yarn 2 on a greenfield project, but discovered: - pnp is made possible in part by mysterious “patches” to certain dependencies that don’t work well with it. Mysterious as in they’re obfuscated, and there isn’t much detail besides commit history. This is blocking if you wanna try out, say, the TypeScript 4.1 beta and the patch isn’t ready yet. But more importantly um... I do not want my dependency manager mysteriously patching stuff with obfuscated code????? - it applies these patches even if you disable pnp, so same objections to the entire yarn 2 approach (currently) So I’m back on yarn 1 and apparently gonna need to look at npm 7 at this point.

eyelidlessness 6y ago
I wrote the above before caffeine really kicked in, so I neglected to add: pnp is itself achieved in part by obfuscating your entire dependency tree. That takes a loooot of trust, on a matter where trust has already exceedingly deteriorated. In hindsight, I regret even considering it.
- acemarke 6y ago
  Can you clarify what you mean by "obfuscating the dependency tree"?
  - desert_boi 6y ago
    They probably mean the idea that once you're in PnP, you can "kind of, sort of" peer into zipfs deps, but not in the same way that was possible in bare node_modules. That said, I think yarn 2's PnP + zero installs (https://yarnpkg.com/features/zero-installs https://yarnpkg.com/features/zero-installs) is lovely with CI. Instead of tacking 40+ seconds to resolve deps every build, vending deps with PnP on is much cheaper than the node_modules equivalent.
  - eyelidlessness 6y ago
    A gigantic single file encoded version of `node_modules` is just modules I can’t go look in.

untog 6y ago

I'd push back against "serious JS codebase", there. Maybe it's just me but a monorepo with 180 packages sounds like a hole you've dug yourself into and you're propping yourself up with yarn. I certainly don't think that anyone who keeps their packages separate (you could do that even within a monorepo, surely) has a "non-serious" codebase.

crubier 6y ago
Well yarn exists for this purpose so I guess I’m not the only one doing this. And if the alternative involves having to manage independent versioning of 180 packages and their inter-dependencies then no thanks. I’m not saying the situation is completely perfect (yarn v2 had its rough edges in the beginning for example), but it’s not too bad either. This monorepo is the best organized codebase of this size and diversity I’ve ever seen. Feel free to explain alternative methods to manage 180 packages with 7 developers while sleeping at night.

croes 6y ago

Some would say the same about NodeJS especially since Deno exists.

lhorie 6y ago

We have a pretty large monorepo codebase (460 packages and counting) that we're migrating from yarn v1 to yarn v2. I'll say it's definitely not a plug-n-play migration (pardon the pun). Some issues we ran into: - it can be difficult to reason about the layout of peer dependencies. Often times libraries that rely on Symbols or referential equality break and you need to mess with packageExtensions or add resolutions or unplug. Debugging mostly consists of throwing stuff at a wall and see what sticks - file watching at large enough projects breaks w/ file descriptor exhaustion errors, forcing you to find and unplug the offending libraries - there's a number of known incompatible libraries (flow being one of the most prominent) and the core team approach to these at this point follows paretto (20% effort for 80% results, e.g. special casing for typescript), meaning I don't believe there will ever be a 100% compatibility milestone w/ the ecosystem - it's much more black-boxy in terms of day-to-day debugging (e.g. it's much harder to manually edit files in node_modules to trace some root cause) - we ran into inscrutable errors deep in packages that interface w/ C++ and basically were only able to fix by pinning to an earlier version of a library that did not depend on said package. - migration cost is heavily proportional to codebase complexity. My understanding is that Facebook gave up on it completely for the foreseeable future and ours has similarly been a significant time investment (and we're not even targeting strict mode yet) The pros: - install times and project switching times are indeed fast, even in our codebase that contains multiple major versions of various packages - yarn v2 has many interesting features, such as protocols (though it's debatable if you want to commit to lock-in to benefit from those)

acemarke 6y ago
From what I've seen, the "unplug" command is supposed to allow you the ability to temporarily unzip a package so that you can do the traditional "hand-edit a file in a dependency" debugging approach.
- lhorie 6y ago
  Yes, but when you're dealing w/ transitive dependencies, often times you need to jump between many packages. And you then need to clean up after your debugging since you typically don't want to leave things unplugged if they don't need to be (as that affects performance). I'm not saying it's impossible to debug, just that you end up having to jump through more hoops.

madjam002 6y ago

Yarn 2 is very nice. The portal: protocol is great and it works well with Nix package manager.

vosper 6y ago

Did you try out pnpm, by chance? I’ve read a few good things, but it doesn’t seem to get mentioned all that often. So I’m curious what people with larger projects think about it. https://pnpm.js.org/ https://pnpm.js.org/

andrew_ 6y ago
I use it in some rather large repos and am a very big fan. It's simply fantastic for every type of repo and project I've thrown it into.
crubier 6y ago
I did try it but it caused two problems as compared to yarn v2: the dependency resolution algorithm seems less deterministic or strict, causing version incompatibilities that yarn v2 did solve, and also the symlinks are poorly supported by many tools (nextJS until very recently, react native etc...). Also the install is longer with pnpm. However it has less runtime performance impact.