fix: Add types to exports field in package.json to resolve type errors

[doinki]

closes: #367

[zpao]

Bah I thought this was working fine :( Thanks for sending a fix!

Not at a computer to test something but I'm curious if this would have been fine if the .d.mts was moved into lib/esm...

[doinki]

@zpao I tested it by moving only the lib/index.d.mts file to the lib/esm/ directory without adding the type to the exports field, but I still get a type error.

When I renamed lib/esm/index.d.mts to lib/esm/index.d.ts, the type error no longer occurred.

[zpao]

Ok back to a computer. Thanks for testing! I was wondering if there was some default behavior we could piggyback on.

That said, I'm struggling to reproduce the issue with the published package :( I think what you have is technically better so we should still do it but would like to pinpoint the precise conditions that cause the problem. I created a theoretical minimal test case - https://gist.github.com/zpao/af370e6d6a08a07740b8c80b0b76ada2. I used pnpm since you were, but couldn't repro with npm either. I tried node 18, 20, 22, but no luck. Is there perhaps a specific version of node or typescript that does make it happen?

[doinki]

@zpao
Oh, sorry. The problem is reproduced when module, moduleResolution, and strict are set as follows in tsconfig.json.

{
  "compilerOptions": {
    ...,
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "strict": true
  }
}

And I tested it by creating a project with next.js.

pnpm create next-app@latest

[zpao]

Ah, I should have just set up Next.js and tried that. Looks like "moduleResolution": "bundler" also triggers the issue. Either option alone or together are a problem. fun.

Ok, I think it might be safe to remove the main and module fields and just rely on exports but I don't want to mess with that in a patch release, so what you have lgtm.

Thanks for sticking with me here!

[zpao]

Thank you!