NodeNext module resolution strictly obeys exports, so for any exported file xxx.js, it looks for types in xxx.d.ts. I'm importing @react-rxjs/core in a web context, which maps to ./dist/core.es2017.js. Therefore, TypeScript expects the types to be found in ./dist/core.es2017.d.ts.
According to https://github.com/microsoft/TypeScript/issues/52363, this behavior is by design, and the recommended course of action is to update the types files in the imported package. It seems unfortunate that multiple copies of the types file are needed, but I suppose each export version might actually have different types, which is why this would be needed.
Update: @rx-state/core is a type dependency of @react-rxjs/core. Fixing both is required for clean compilation. I suspect multiple other sibling libraries share the same issue.
NodeNext module resolution strictly obeys
exports, so for any exported filexxx.js, it looks for types inxxx.d.ts. I'm importing@react-rxjs/corein a web context, which maps to./dist/core.es2017.js. Therefore, TypeScript expects the types to be found in./dist/core.es2017.d.ts.According to https://github.com/microsoft/TypeScript/issues/52363, this behavior is by design, and the recommended course of action is to update the types files in the imported package. It seems unfortunate that multiple copies of the types file are needed, but I suppose each export version might actually have different types, which is why this would be needed.
Update:
@rx-state/coreis a type dependency of@react-rxjs/core. Fixing both is required for clean compilation. I suspect multiple other sibling libraries share the same issue.