cannot resolve esm-only modules with import condition and yarn pnp
#204
Comments
|
Investigating such issues with higher-order meta frameworks is time-consuming. I appreciate it if you can make a minimal reproduction (with jiti only). closing in the meantime. |
|
@pi0 will creating a minimal reproduction (with jiti only) lead to the issue being fixed in a timely manner? |
|
minimal reproduction it is a requirement to make valid issues. priority is based on how common a feature/bug is. |
|
Here's a minimal reproduction using only jiti. Steps:
Also, read this comment solidjs/solid-start#1177 (comment), it might save you timeYou should see this: Please understand that all I'm trying to do is build a website using solid-js and latest yarn (because solid-js is awesome) and I'm already multiple levels deep of debugging and opening issues. I would be very happy if you could fix this and very disappointed if you don't (although the mlly bug is more severe for me). To give you some incentive, google "yarn berry" and read about everyone using it - don't you want to enable those people to use your library? |
|
Thanks for making reproduction 👍🏼 |
|
Some context: jiti is an ESM+Typescript compatibility layer for Node.js. You might think ESM is stable and fully supported in Node.js but that's sadly not completely true. Node.js provides no stable loader mechanism (to support TS) nor an invalidation API for ESM Modules (to support reloading a config file without full process restart!). Because of this jiti is depending on Node.js CJS modules to resolve this limitations but also pushing ESM forward. The Adding to the all complexity, yarn (which I love and used since early days!) pnp uses hacky methods to allow resolving from virtual modules and it (recently) supports a compatible polyfill for I think the right solution for this might be relying on For jiti v1 that is used by solid, we might also enable this fallback support behind a flag but really a simpler solution is that vinxi's package.json could simply use Also for the follow up, I have tried to directly unplug |
pi0
changed the title
import condition and yarn pnp
|
Thanks a lot for looking into this, explaining the context and giving recommendations to the solid-start team @pi0 :) Great that you don't hate on yarn, I love it too. I just did Nice that you can fallback to import.meta.resolve in v2 and that it's synchronous now. I think the ball is rolling and I have some patches so solid-start works for me right now 🥳 |
fixes issue with yarn pnp - related to #204
|
Tested against jiti v2 nightly with new ESM API. pnpm had one new strange issue (50e4280) and also shows a warning if the extension is explicitly not set in import breaking internal try-catch of jiti and nothing fixable in jiti... (tested against #204 (comment)) import { createJiti } from "jiti"; // tested against jiti v2 nightly
const jiti = createJiti(import.meta.url);
// Note: Without explicit extension yarn pnp throws error even in internal try-catch block of jiti
const resolvedPath = jiti.esmResolve("./vite.config.ts");
console.log({ resolvedPath });
const mod = await jiti.import(resolve1);
console.log({ mod }) |
Environment
Node 21.5.0, yarn 4.0.2, macOS 14.2.1 (23C71)
Reproduction
See the steps detailed here nksaraf/vinxi#43, vinxi fixed yarn berry compat by disabling jiti when not using a typescript
vite.config.tsfile, but it's still broken due jiti calling require.resolve with the wrong import conditions in the default setup (having a .ts config file)Describe the bug
See also the linked issue above and run the reproduction steps
Additional context
No response
Logs
No response
The text was updated successfully, but these errors were encountered: