Hi! 👋
Firstly, thanks for your work on this project! 🙂
Today I used patch-package to patch resolve-package-path@4.0.3 for the project I'm working on.
Correctly grab pnpapi if the Yarn 3 project is not the same as the process.cwd(). This is useful because this module executes require('pnpapi) as soon as it is required, and that cwd may not necessarily be the one with the project.
Here is the diff that solved my problem:
diff --git a/node_modules/resolve-package-path/lib/index.js b/node_modules/resolve-package-path/lib/index.js
index a1463f7..00d83b8 100644
--- a/node_modules/resolve-package-path/lib/index.js
+++ b/node_modules/resolve-package-path/lib/index.js
@@ -89,6 +89,14 @@ function resolvePackagePath(target, baseDir, _cache) {
// the custom `pnp` code here can be removed when yarn 1.13 is the
// current release. This is due to Yarn 1.13 and resolve interoperating
// together seamlessly.
+ if (!pnp) {
+ try {
+ pnp = require(require.resolve('pnpapi', { paths: [baseDir] }))
+ }
+ catch (e) {
+ // not in Yarn PnP; not a problem
+ }
+ }
pkgPath = pnp
? pnp.resolveToUnqualified(target + '/package.json', baseDir)
: (0, resolve_package_path_1.default)(cache, target, baseDir);
This issue body was partially generated by patch-package.
Hi! 👋
Firstly, thanks for your work on this project! 🙂
Today I used patch-package to patch
resolve-package-path@4.0.3for the project I'm working on.Correctly grab
pnpapiif the Yarn 3 project is not the same as theprocess.cwd(). This is useful because this module executesrequire('pnpapi)as soon as it is required, and thatcwdmay not necessarily be the one with the project.Here is the diff that solved my problem:
This issue body was partially generated by patch-package.