-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doesn't work with yarn pnp and esm-only modules with import
condition
#221
Comments
Investigating such issues with higher-order metaframeworks is time-consuming. I appreciate it if you could make a minimal reproduction (with mlly utils only). closing in the meantime. |
Minimal reproduction:
Output should look like this:
|
Sorry I included some paths from where I reproduced the issue as part of solid-start in above, but the same error can be observed without them with just
|
mlly
doesn't work with yarn berry (pnp)import
condition
Thanks for the reproduction. I think same as unjs/jiti#204 (comment) for jiti, for mlly we can leverage Faster solution for module authors is using |
Hey @pi0! Hope you're well :). I'm invested in making this work, so we can use yarn pnp with unplugin-icons (see also unplugin/unplugin-icons#358). I've made an early draft of a fix at #270. The code isn't well organized or anything; I'm looking for feedback on approach, where to put the safe resolve call, etc, before I adjust it more. Could you take a look? I've tested the fix on both my own code and the minimal repro above; it fixes both. However, note that I tested only using a yarn patch -- I can do that once we've got the structure down, as final QA before merge. |
Environment
Node 21.5.0, yarn 4.0.2, macOS 14.2.1 (23C71)
Reproduction
git clone [email protected]:danieltroger/vinxi-repro.git
cd vinxi-repro
yarn
yarn build
Describe the bug
Using yarn pnp (please see https://yarnpkg.com/features/pnp) modules have to be resolved very differently, since node_modules is a concept of the past there - instead, we have de-duplicated, compressed .zip files containing our dependencies.
It seems like mlly is a re-implementation of node-js' module resolution algorithm that has never heard about yarn berry. And because yarn berry doesn't patch mlly, it just explodes when being ran with yarn berry.
Additional context
I really need yarn berrys workspace, package deduplication, patching and linking features and I updated a project to the new solid-start to which mlly is a peerDependency. I'd suggest you to just re-export the working
import.meta.resolve
when detecting yarn berry since this project seems redundant to me today.Logs
The text was updated successfully, but these errors were encountered: