Misconfiguration for typescript projects using module node16/nodenext

[ScripterSugar]

trafficstars

Hi.

I'm currently working on ESM repo with tsconfig moduleResolution set to node16, and this library has misconfigured type definition that confusing typescript when we try to import default export from the module.

In current configuration, the library's seems to have so-called double-default problem described in typescript repo.

Reproduce

In a project with package.json "type": "module" tsconfig.json "moduleResolution": "node16"

While trying to import default export from weaviate-ts-client, typescript's expectation and actual runtime value mismatches

import weaviate from 'weaviate-ts-client';
console.log(weaviate.client); // ts error; Property 'client' does not exist on type

// Typescript expect it to be
// {
//   default: {
//     client: (params: ConnectionParams) => WeaviateClient;
//     ApiKey: typeof ApiKey;
//     AuthUserPasswordCredentials: typeof AuthUserPasswordCredentials;
//     AuthAccessTokenCredentials: typeof AuthAccessTokenCredentials;
//     AuthClientCredentials: typeof AuthClientCredentials;
//     EmbeddedOptions: typeof EmbeddedOptions;
//   };
// }

// But it's actual value in runtime is
// {
//   client: (params: ConnectionParams) => WeaviateClient;
//   ApiKey: typeof ApiKey;
//   AuthUserPasswordCredentials: typeof AuthUserPasswordCredentials;
//   AuthAccessTokenCredentials: typeof AuthAccessTokenCredentials;
//   AuthClientCredentials: typeof AuthClientCredentials;
//   EmbeddedOptions: typeof EmbeddedOptions;
// };

You can see arethetypeswrong also indicates the repo is misconfigured in the exact way as I described above.

It seems like node16's module resolution strategy and typescript's following implementations making a lot of trouble in ecosystem and making quite a bit of confusions all over the place, as you can see from

https://github.com/microsoft/TypeScript/issues/50058 https://github.com/microsoft/TypeScript/issues/49160 https://github.com/vitejs/vite-plugin-react/issues/104

I'm afraid that I can't really tell what's the workaround for this as it's really confusing for me that what's the problem at the first place..

I might be wrong here, so feel free to point me out. It'd be much appreciated if someone can analyze the details regarding to the problem.

[yepesJuan]

Still not fixed. Alternatively, go back to "moduleResolution": "node"

[MellKam]

Can you just make a named export for client function? Because that's the only thing we can't get without using the default export.

At the moment I'm doing something like this to ignore typescript errors:

(weaviate as unknown as typeof weaviate.default).client({ ... })

[TimPietrusky]

@MellKam thanks, that is working!

[tsmith023]

I'm happy to announce that this is fixed in the next major release! It's currently in an open community beta and installable using npm install weaviate-client --tag beta. I will leave this issue open until the new package reaches GA