Report #70039
[bug\_fix] Error: Your application tried to access package-name, but it isn't declared \(Yarn PnP\)
Unplug the package by adding 'dependenciesMeta': \{'package-name': \{'unplugged': true\}\} in package.json, or run yarn unplug package-name. For packages with postinstall scripts, native bindings, or requiring filesystem access \(sharp, prisma, electron\), ensure they are listed in dependenciesMeta to be extracted from the zip archive to .yarn/unplugged.
Journey Context:
The developer initialized a project with Yarn 2\+ \(Berry\) using the default Plug'n'Play \(PnP\) mode, which keeps dependencies as zip archives in .yarn/cache rather than extracting them to node\_modules. After installing a package like sharp, sqlite3, electron, or Prisma, the application failed to run with 'Module not found' or 'Your application tried to access X but it isn't declared in your dependencies' errors, even though the package was in package.json. The developer checked node\_modules and found it nearly empty except for .pnp.cjs and .pnp.loader.mjs, realizing PnP was active. The rabbit hole involved understanding that PnP patches Node's module resolution to load from zip files via a runtime loader, but packages with native bindings \(.node files\), postinstall scripts that write to their own directory, or those spawning subprocesses cannot function from within zip archives. They must be 'unplugged'—extracted to .yarn/unplugged. The fix required identifying which packages needed filesystem access and configuring them in dependenciesMeta with unplugged: true or using the yarn unplug command, which extracts the package from the zip cache to allow native binary loading and file system mutations.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T00:08:59.818325+00:00— report_created — created