fix: find the pnpapi the issuer belongs to
#301
Conversation
|
I think better to fix it on yarn side? |
@alexander-akait Can you elaborate on how it could be fixed on the yarn side? Thank you for your input! |
|
It's not really a bug on our side, |
|
@sokra @alexander-akait ^^^ Bump 😄 |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #301 +/- ##
==========================================
- Coverage 92.85% 92.47% -0.38%
==========================================
Files 43 44 +1
Lines 2042 2061 +19
Branches 598 603 +5
==========================================
+ Hits 1896 1906 +10
- Misses 118 125 +7
- Partials 28 30 +2 ☔ View full report in Codecov by Sentry. |
|
@alexander-akait @sokra Just wanted to check-in again if you could help provide any insight on how to approach a fix for this issue? Again, I'm more than willing to help fix it too. I've tried digging into this to figure out another way to help fallback to alternatives, but with the plugin system, I was getting lost as to how the flow of resolution works and where one might be able to intersect and fallback. I've also reached out to @arcanis to help provide any insight, and I think we're all kind of stuck. Anything would be greatly appreciated! Thank you! |
|
Let's wait @arcanis answer, I am not against these changes |
|
How to reproduce a scenario where you have packages that are yarn managed and packages that are non-yarn managed? |
@sokra I'm sorry for not including that. Here's a link to a repo to reproduce that's using this patch as the fix: https://github.com/jgornick/yarn-webpack-node-modules-to-pnp |
@sokra Please let me know if there's anything else I can provide or help with 😄 |
|
@sokra @alexander-akait ^^^ Bump again 😄 Specifically looking for any information with how to resolve #301 (comment). I have a reproducible repository setup at https://github.com/jgornick/yarn-webpack-node-modules-to-pnp Thank you! |
|
I think the main issue here though is that enhanced-resolve doesn't have a way to fallback if this the PnP Plugin can't resolve a package. @merceyz is highlighting the issue here: https://github.com/webpack/enhanced-resolve/pull/301/files#diff-484df5a516d012258b8eb71e51625ef132b1c571ef3756b7c45433f4365e2e69R61 |
|
@jgornick Can you fix lint? |
merceyz
force-pushed
the
merceyz/feat/multi-root
branch
from
7e34064
to
80a01c9
Compare
|
I'll try to look at adding tests sometime today. Is it fair to say that out of the |
|
Bump ^^^ @sokra @alexander-akait 😄 |
|
I would prefer if the |
|
@sokra and @alexander-akait ... There should be a commit coming from @merceyz that should fix this issue so that if PnP is available, but still can't resolve a module, it'll fallback to trying node_modules again. The only question I have is how can I satisfy the code coverage issues, especially in ResolverFactory? In order to test this, we'd have to mock a module so that the One option I was thinking of is what if we made the Thank you!
|
merceyz
force-pushed
the
merceyz/feat/multi-root
branch
from
1571df9
to
c53553c
Compare
|
@TheLarkInn and @alexander-akait Looks like this should be good to go. |
@TheLarkInn Just wanted to check-in to make sure you're good with the changes here? |
|
@TheLarkInn and @alexander-akait: Bump 😄 |
|
Sorry for the weekly bump @alexander-akait and @TheLarkInn, but just trying to get this through as I think we're finally all ready to go 😄 |
|
Weekly bump @TheLarkInn 😄 If we can get you to remove the changes requested flag, then we can at least get the workflows to run. |
|
Bump 😄 @alexander-akait, is there anything you can do to remove the blocker on here from @TheLarkInn? |
|
Just checking in again on this PR to see if we can get it merged? |
|
👋 Hey, it's me again 😄 Would love to get this merged so that we can stop referencing a custom build of enhanced-resolve. |
|
@TheLarkInn Is there anything still blocking the merge? |
lib/ResolverFactory.js
Outdated
| @@ -5,6 +5,7 @@ | |||
|
|
|||
| "use strict"; | |||
|
|
|||
| const findPnpApi = require("module").findPnpApi; | |||
There was a problem hiding this comment.
Let's remove it from the top of file and put it inside processPnpApiOption
|
I'm a little concerned about performance, we need improve it |
|
@alexander-akait Thanks for your update. I labeled the Pull Request so reviewers will review it again. @TheLarkInn Please review the new changes. |
|
Thank you @alexander-akait! |
This PR upgrades `enhanced-resolve` to `5.16.0` so as to benefit from webpack/enhanced-resolve#301, recently merged. Without this diff, importing dependencies from files from external PnP projects would fail. It's a little niche, but I'm working on a documentation website that leverages that to allow deploying multiple websites from the same template. Co-authored-by: Sam Ko <[email protected]> Co-authored-by: Steven <[email protected]>
What's the problem this PR addresses?
enhanced-resolveis outside the control of thepnpapiand can't require itissuermight not belong to the samepnpapiasenhanced-resolveissuermight not belong to apnpapiat all and should use thenode_modulesresolution insteadFixes arcanis/pnp-webpack-plugin#32 for Webpack 5
How did you fix it?
Use
module.findPnpApito locate the correctpnpapifor theissuer, if apnpapiisn't found continue the normal resolution