Closed sannajammeh closed 3 months 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.
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
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.
@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
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.