https://serverless-stack.com/ logo
Join SlackCommunities
Powered by
Does anyone have opinions on the yarn plug'n'play ...
# random
t
Does anyone have opinions on the yarn plug'n'play spec? Trying to figure out if it's really the direction things are headed in when tools like pnpm exist that make things super fast even without pnp
g
I think its bound to fail 😐
There seems to be some inflexibility from the lead which has been met with pushback from e.g. the typescript team (they're not happy with a JS file having to be evaluated, they were asking for a different more declarative approach)
overall I think the idea hasn't received much acclaim in the wider community. the first thing I see people do when they install yarn 3 is to set up the node_modules nodeLinker
t
yeah there's certain patterns (admittedly maybe things that are anti-patterns) which are common in the ecosystem that break with pnp
but it's things that cdk does and we don't have control over
yeah I agree I've seen the same thing, setting it back to nodelinker. Also a part of me feels like it's really odd to generate a single file - I understand the benefits but I don't think I know of any other dependency management system that operates that way
g
In theory the idea is good, have just one global store of immutable modules on the filesystem, then use a map to tell node where it can find them
t
I'm a big nix fan so I like that idea as well but the implementation with a virtual file system that points to a file is a bit weird. It makes referencing assets that aren't code tricky (common in cdk where they deploy function code on your behalf)
pnpm feels more like the nix approach and I'm in process of learning more about it so I can move my own workflows to it
g
pnpm is pretty great, but I just can't let go of yarn v1, mainly because of how fast and flexible 
yarn run
is 😄
in practice there is some discussion about the design of pnp here https://github.com/microsoft/TypeScript/pull/35206
t
yeah yarn1 is what I've been using for everything right now
g
We're still not willing to call out to arbitrary JS during our execution without a proper plugin model ready, and the "pnp API" is still arbitrary JS code and not a manifest we can directly consume
that's been one of the comments from the TS team
additionally with tooling increasingly moving to Rust and Go, it seems like this design decision in PnP might prove to be problematic
And in general, I am a bit weary of the lead's approach to these things. See for example this response:
This point in particular got discussed a few times already (for example here), but I think the TS team demonstrated since then why the executable format is just fine: the data format actually got implemented in May 2019 - a year and a half ago - but it didn't do anything to bring PnP closer from TS. Given that it was literally its only purpose, it shows that we should optimize the format for the convenience of our team rather than for theoretical use cases.
not a great look. this is the TS team, they got a lot of experience designing languages and tools that goes beyond the JS ecosystem too. I would not dismiss their concerns as theoretical.
t
yeah that's a good point about tooling languages not being in js
g
raised by esbuild author too https://github.com/evanw/esbuild/issues/154
t
oh interesting, this has all been really convincing
esp if esbuild isn't considering it since we're very tied in with it
g
I believe yarn berry themselves have authored a plugin for esbuild that adds the support
t
thanks for all of these details, went from sorta feeling like pnp wasn't worth explicitly supporting to definitely feeling like we shouldn't bother until these other big projects make a decision
g
although I still don't understand why they don't take the feedback to switch to a static JSON format instead of building patches for all other tools in the ecosystem 😞
Honestly, I think its a grand idea, but executed poorly, with attempts to pressure projects into adoption or doing DIY patches and plugins for them, rather than working together on concerns
Open in Slack
PreviousNext
Powered by