SebastianVerified account

Unfortunately we've had to disable @yarnpkg PnP at Facebook due to instability. We'd recommend thorough testing before deciding to adopt it in your codebase.

What were the biggest obstacles / sources of issues?

cc @cpojer @rickhanlonii

For context, our JS setup for RN is gigantic. There is tons of custom JS infrastructure, most of which makes more or less sense or was born out of necessity.

PnP is a fantastic idea but it was never fully deployed at Facebook. Two important tools like Flow and Buck didn’t receive proper PnP support. When engineers ran those, which at FB anyone writing JS will often, Yarn would opt out of PnP and do a full node modules install.

As most people triggered at least one full node modules install because of this, we didn’t gain the performance advantages (no install time) that we wanted, we just deferred it. In some cases it was even worse, doing more node modules installs than necessary.

The second major issue was frequent ecosystem incompatibility with third party packages. It takes a lot of work to keep things stable and active maintenance but unfortunately we didn’t have time to maintain this infra.