[eyelidlessness]

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]

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]

Can you clarify what you mean by "obfuscating the dependency tree"?

[desert_boi]

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) 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]

A gigantic single file encoded version of `node_modules` is just modules I can’t go look in.

[eyelidlessness]

(Not a real edit): my last gig was with a lot of well prepared juniors, but they lacked the confidence to go look inside dependencies to find out what was happening. I tried to encourage setting breakpoints or logging or whatever felt comfortable in required packages. It was hard.

Turning that into a blob is even more discouraging.

[acemarke]

As I mentioned elsewhere in the thread, Yarn v2 does have an "unplug" command that will extract a given dep into a folder for the time being. Does help with that use case.

[eyelidlessness]

And if you trust that they’re fundamentally the same thing, that’s a great escape hatch. I personally tried to use two new things together and discovered that one is transparent and one is opaque magic... and given the opportunity to do harm, I found the opacity of one alarming. I don’t trust yarn to manage dependencies in pnp, because what I saw in how they handled a special case was completely black box. Literally binary blob patches with no explanation of what it’s doing or why. Completely impossible to audit without reverse engineering or auditing the entire tool. Why would I trust “unplug” to do anything but misdirect?

[acemarke]

What "binary blob patches" are you referring to?

FWIW, if I wanted to confirm whether an "unplugged" package had been modified, I'd just download the original tarball from NPM, extract it, and diff the two folders.

[chrisweekly]

Sorry if this makes it harder but I honestly recommend reading up on pnpm (https://pnpm.js.org/) before committing to npm7. Npm7 auto-installs peer dependencies(!) and pnpm has some remarkable advantages over npm or yarn.

[crubier]

Pnpm is indeed better than npm but I found it’s symlinking approach less compatible than yarn v2, (nextJS for example didn’t support pnpm until very recently) while also having less deterministic module resolution, creating version compatibility problems that disappeared with yarn v2.

[eyelidlessness]

I had already been meaning to look at it but had written it off because I wanted what yarn 2 was selling... but definitely gonna give it another look.