Verify `export =` vs `export default` for CJS about arethetypeswrong.github.io

[remcohaszing]

postcss-image-set-function uses module.exports =, but its type definitions specify export default.

https://arethetypeswrong.github.io/[email protected]

[andrewbranch]

Is there an example of this in a real package I can look at?

[andrewbranch]

Ah, I thought this would be an easy fix, but it looks like I should probably address this note:

arethetypeswrong.github.io/packages/core/src/problems.ts

Line 128 in baf720c

// Also need to check for `default` property on `jsModule["export="]`?

before expanding the scope of this rule, which requires bringing the type checker into play, like #22 also requires. Turning the rule on for other resolution modes (I think it was an accident that I didn’t before) made postcss really blow up, because it can’t identify the pattern:

module.exports = AtRule
AtRule.default = AtRule

that they use throughout, which should not trigger the FalseDefaultExport problem.

I started some work on type checking / whole program support a few days ago, but I’m still just working on this in my spare time.

[remcohaszing]

Another one is [email protected]. (It’s fixed in newer versions.) It’s reported as an issue for ESM, but really it’s an issue for CJS.

When compiling a default import to CJS consuming that package, those types are fine. However, when manually writing CJS and using checkJs, it’s not nice to use such types.

It’s different though, because unlike postcss-image-set-function, [email protected] at least could be used without esModuleInterop.

[not-my-profile]

I think it would make sense to display a ? for the node16 (from CJS) row instead of a ✅ until this issue has been fixed since claiming that the types are ok when they're not is misleading and confusing.

Or perhaps add a disclaimer that all ✅ are to be taken with a grain of salt since this tool doesn't yet support type checking.