huozhi / bunchee

Zero config bundler for ECMAScript and TypeScript packages
https://npmjs.com/bunchee
859 stars 28 forks source link

When codesplitting on server runtime, `.js` with typedefs files are created instead of `.d.ts` #547

Open sannajammeh opened 2 weeks ago

sannajammeh commented 2 weeks ago

image

Adding .server-runtime or .shared-runtime to a file causes the bundler to codesplit correctly, but rather than creating a corresponding .d.ts extension file it will add a .js extension and dump the declarations in there.

amannn commented 2 weeks ago

I just ran into the same issue.

Here's a reproduction: https://github.com/amannn/bunchee-test/commit/a9e6ce62d5f8ff0d99a3f3ee0b0a7c00fdee592a

The relevant part is that there's a type created in the shared runtime that is then referenced in an entry point. As a result, the file dist/utils-shared-BdVwpBM3.js is created which contains only the type declaration and should therefore use .d.ts.

Using a .js file causes a TypeScript error for consumers in my project:

TS8017: Signature declarations can only be used in TypeScript files.
huozhi commented 2 weeks ago

It seems have some issues with codesplit, maybe I should mark this shared-runtime feature as experimental..as it's not super reliable now. I would probably go with sth else in #540

sannajammeh commented 2 weeks ago

It seems have some issues with codesplit, maybe I should mark this shared-runtime feature as experimental..as it's not super reliable now. I would probably go with sth else in #540

We might stay on this route as we heavily rely on .server-runtime. We had issues where a client module still wouldn't codesplit correctly until the server module was marked .server-runtime

I hope #540 also supports react server only runtime declarations.

sannajammeh commented 1 week ago

@amannn @huozhi As a temporary fix, I implemented a postbuild step which assumes the default structure from bunchee prepare. Modify it to your liking.

https://gist.github.com/sannajammeh/0d2ef984d9a076a90dae9ba27910ea5e