Dexter sub-path imports don't seem to work without tsconfig "moduleResolution": "Bundler"

[transitive-bullshit]

Using "moduleResolution": "node" in the consuming project, which is very common, seems to break dexter's typing exports as tsserver can't find them.

Example:

import { type Prompt } from '@dexaai/dexter/prompt` // this gives an error

This will probably surprise anyone who tries to use this package, since before 2 weeks ago, I had never used "moduleResolution": "node".

It would be nice to use tsc only, but I wonder if we'd be better off using something like tsup for output compatibility?

[transitive-bullshit]

@rileytomasek what do you think of switching all example usage to import from @dexaai/dexter? We can keep the ESM exports to remain backwards compatible.

Reasoning:

• The current exports version is broken in many TS projects (including all 3 of my own projects I've tested it on)
  • Fixing this would likely be a headache and possibly involve re-adding something like tsup OR requiring moduleResolution: "bundler", which I feel like is a non-starter for a general NPM package
• I know a lot of people have auto-imports, but DX-wise not everyone does, and I've found having multiple imports from dexter to be a pain so far.
• As we add additional functionality to dexter (more providers, chunking, etc), this DX issue will only get worse
• We can still keep the ESM exports if devs care about optimal imports for edge/serverless use cases, but right now all of our usage is Node.js, so we're really not gaining anything from not having a simple entrypoint

[rileytomasek]

"moduleResolution": "node" is not the correct configuration for an ESM project — the correct values are bundler, node16, or nodenext. Sindre explains more here. Our time is better spend improving the library that providing compatibility with legacy CJS.

Adding root exports will likely just make this even harder to debug because then the import may work and it will fail deeper into the code.