Add the types condition to the package.json#exports

[Andarist]

This is required for TypeScript to work with packages that have exports when using the new moduleResolution: node16/nodenext/bundler settings. When those are not used then TypeScript just ignores package.json#exports - but when you make it aware of exports by using those options then it requires the types to be included in exports and not as the top-level key of package.json

[andrewbranch]

This is an improvement, but may still cause problems. The correct solution is to add an index.d.mts file. See “Types are CJS, but implementation is ESM” at https://github.com/arethetypeswrong/arethetypeswrong.github.io.

[Andarist]

I find it harder to reason when the types condition is not there because it's implicit/hidden from the reader. exports promote explicitness and I think it's good to extend that to types as well. Of course, YMMV and you might have your own opinions etc. I wonder though - would this be correct here?

{
  "exports": {
    ".": {
      "import": {
        "types": "./dist/index.d.mts"
        "default": "./dist/index.mjs"
      },
      "require": {
        "types": "./dist/index.d.ts"
        "default": "./dist/index.js"
      }
    }
}

I guess that this would be correct but it would come with a super small perf penalty as the runtime would have to resolve one more level of nesting.

[andrewbranch]

Yes, that would work. The perf penalty is negligible.

[Andarist]

Both files could have the very same content, right? They can't "proxy" to the same file though, IIUC. So this solution would require me to copy the .d.ts file and save it with a different extension.

[andrewbranch]

Yes, or have the ESM types re-export from the CJS types.

[Andarist]

I pushed out what I believe is correct now. Would you mind taking another look at this @andrewbranch ?

However, this particular module might still have problems.

The generated .d.ts contains import { Plugin } from 'vite';. And on that line we get:

The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("vite")' call instead.ts(1479)

Note that Plugin is only used as a type here but I can't make it work with both import type and import { type Plugin }.

A separate thing is that Vite is a module - that cannot be required but they provide a require condition. However, I'm not sure how one would re-export their module-based .d.ts as .d.cts

[andrewbranch]

You should be able to use an import type—import("vite").Plugin. This still resolves with the resolution-mode of the file (CJS in this case), but on the checking end, is allowed to resolve to an ES module. Note also that I’m planning to investigate whether type-only imports can be allowed to resolve to ES module from CJS modules: microsoft/TypeScript#52529.

[Andarist]

You should be able to use an import type—import("vite").Plugin.

In this instance, it's quite problematic because this whole thing is generated by tsup. So I don't have a lot of control over this (I think?).

Note also that I’m planning to investigate whether type-only imports can be allowed to resolve to ES module from CJS modules: microsoft/TypeScript#52529.

This would be sweet

[init-center]

@gxmari007 can you merge this PR to fix the error:
There are types at '/Users/xxx/Desktop/my-project/node_modules/vite-plugin-eslint/dist/index.d.ts', but this result could not be resolved when respecting package.json "exports". The 'vite-plugin-eslint' library may need to update its package.json or typings.

[rtmann]

Not the ideal end solution, but you can also just turn off typescript's enforcement of this in your tsconfig.json

        "resolvePackageJsonImports": false,
        "resolvePackageJsonExports": false,

Another option is you can use patch-package and just modify the package.json you want to add the exports/imports to and then apply the patch in your project.