Clarity on node16 importing CJS from ESM about arethetypeswrong.github.io

[andrewbranch]

• @use-guesture/core: This is not a dual package as far as Node is concerned. The exports conditions used are module for the “ESM” files and default for the CJS files. Node does not set the module condition, so this will never be reached by Node without specifying custom conditions. If you were to supply a custom condition of module in Node and TypeScript, a few things would happen. First, TypeScript would see everything as untyped, since only the CJS files have .d.ts counterparts. Secondly, Node would crash, because the *.esm.js files are CJS modules according to file extension and package.json type, but use ESM syntax, which is an error. Building with a bundler that sets the module condition (which is surely what the package authors intended—doesn’t make much sense to run this library in Node) may work fine (in my experience, some pay attention to the package.json type and others don’t), but TypeScript would still be unable to find the types if the module custom condition was also supplied in the tsconfig. However, the types for the CJS files would probably work fine under the default --moduleResolution bundler config, so this scenario may accidentally work out of the box. In summary, this setup is probably working everywhere, but seems a bit fragile and confused.
• @razorpay/blade: This package is completely broken in Node, because like @use-gesture/core, the files are using ESM syntax but will be detected as CJS in Node due to file extension and lack of package.json type. This would be a good validation error to add to this project.
• @adobe/react-spectrum: The above explanations probably answer your question about why this is different. This package is broken in the most common, predictable way I’ve seen, which is why the tool can diagnose it with a specific explanation. The issues in the other two packages are things I haven’t specifically considered before.

Nice examples; I’ll look into adding some analysis and explanations to better diagnose these issues. Thanks!

[andrewbranch]

I’m going to reopen this as a way to track adding these specific problem kinds 👍

[andrewbranch]

Apropos of nothing, when I started assigning emoji to problem kinds, I thought there would be way fewer problem kinds 😂

[andrewbranch]

What does the (CJS) mean here exactly?

I forgot to answer this directly, but it may have been apparent—it’s the result of Node’s detection algorithm (mirrored in TypeScript’s modern Node resolution modes) for what kind of module a file is—i.e., what the file extension and package.json type indicate. (If the syntax within doesn’t agree, Node will crash.)

[andrewbranch]

And shouldn't it be a point of concern that node16 from ESM is resolving to the CJS type definition for a package that provides ESM too?

Maybe—that’s why I render it in the table. It’s not listed as a problem because Node and TypeScript agree on what the module kind will be, and it’s not a problem to import CJS files from either ESM or CJS files. The tool doesn’t currently know whether any other files are detectably ESM or syntactically ESM, so there’s nothing that could currently indicate that the package “provides ESM too.” But I think expanding this analysis and raising a warning if ESM files exist but aren’t resolved by Node could be a good addition. On the other hand, it’s definitely possible that a package author includes ESM specifically for bundlers or the browser and intentionally leaves Node on CJS (as may be the case with @use-gesture/core).

[cseas]

Thanks a lot for the detailed explanations! ❤️