Yarn support: Yarn PnP can't find __mf__virtual

[david-at-ds]

When using Yarn PnP + Vite I get this error message:

Failed to resolve dependency: __mf__virtual, present in 'optimizeDeps.include'

And then after the server is started:

4:42:25 PM [vite] Pre-transform error: Failed to resolve import "__mf__virtual/test__mf_v__runtimeInit__mf_v__.js" from "virtual:mf-REMOTE_ENTRY_ID". Does the file exist?
4:42:25 PM [vite] Internal server error: Failed to resolve import "__mf__virtual/test__mf_v__runtimeInit__mf_v__.js" from "virtual:mf-REMOTE_ENTRY_ID". Does the file exist?

[gioboa]

Hi @david-at-ds thanks for your feedback At the moment the project is tested with pnpm and we didn't check it with different package managers. Feel free to drop a PR to solve that.

[libmilos-so]

Hello @gioboa, we're migrating from npm to yarn with pnp and we're encountering the same issue.

I've tried investigating into this a little bit, and I think that the issue is that src/utils/VirtualModule.ts is generating the module directly in node_modules/, which is incompatible with pnp. I guess that it'd need to be adjusted to detect the PnP mode and build accordingly directly inside the package path that Yarn would allow importing from.

If I understand correctly, pnpm's pnp mode works in a similar way, so I've tried to set it up for our project to test it, but I didn't manage to do it yet. Does it currently work on pnpm's pnp?

I'm open to contributing to the module, but since I'm primarily a backend developer with limited JS/TS experience, I'd first like to confirm with you if my conclusion is correct and if this would be the right approach for this. Thanks!

[gioboa]

Hi @libmilos-so thanks for your feedback. Yes, you are right, right now the package is not tested with that environment but I'm more than happy to review a PR to support that.

[moneydance]

Also seeing this issue. I think I'm just going to move to pnpm yarn pnp doesn't seem to be well supported by a lot of library/build tools at the moment.

[pcfreak30]

pnp

PNP really feels like the odd man out as a standard. They are taking a similar route to bun and in a way breaking the node_modules assumption that, good or bad, the last decade of eco building has depended on. PNPM keeps it but creates a very large symlink system instead.

[github-actions[bot]]

As there's been no activity for 30 days, this issue has been flagged as stale. If you'd like it to remain open, please add a comment within the next 7 days. Thank you.

[ha1fstack]

Since there is no discussion tab I'll leave my question here:

Is there any reason for this plugin to use actual fs(node_modules) instead of virtual module in memory? Is it because that the virtual modules are not pre-bundled so it breaks interop imports?

I'm willing to make a PR or suggestion but need some additional context