`moduleResolution` shouldn't be set as `bundler`

[XiNiHa]

Currently, the moduleResolution option of the seroval package is set as Bundler, and this makes users without bundlers unable to consume the package correctly.

Since seroval uses Bundler and doesn't perform any postprocessing of module resolutions before publishing, module specifiers that only work with Bundler gets uploaded as-is on NPM and it breaks users who use stricter moduleResolution options like NodeNext, which forces users to utilize additional tools (bundlers, transpilers, etc) to perform additional module resolution.

If keeping the moduleResolution option as Bundler is desired, it should be fixed in pridepack to perform module resolution process during build to convert all module specifiers to be compatible with NodeNext.

[lxsmnsyc]

hmmmm, I've tried NodeNext before...it's actually the least compatible in my project setups. Bundler hits right for my needs, and it meets the requirement that is in common between runtimes and bundlers. Of course the only thing I'm only doing wrong is that the JS bundles aren't colocated with their type definitions.

This will remain unchanged until I'm convinced.

[XiNiHa]

it meets the requirement that is in common between runtimes and bundlers

Do you mean the part that alternative runtimes like Deno can't resolve files when .js extension is used? I believe that should be handled using allowImportingTsExtensions and rewriteRelativeImportExtensions, not by using Bundler.

Using Bundler in a library without any postprocessing results in a major breakage: (ref)

As you can see, the library is completely broken for users who use NodeNext. This is not good, especially because every library that depends on seroval should also use Bundler to use the library, leading to more breakage in the whole ecosystem. Considering all of these, could you reconsider about moving away from Bundler?