search

sebastianwessel / surrealdb-client-generator

Tool which generates a typescript client for SurrealDB and zod schema of a given database
MIT License
77 stars 12 forks source link

feat: allows to choose the extension of importation #49

Open yassinrais opened 4 months ago

sebastianwessel commented 4 months ago

Hey, thanks for your pr. But, what is the purpose or use case for importing *.ts? Normally, you always use the .js extension - even if the source file is a *.ts, you need to import it as .js. See official typescript documentation.

From a personal view, the whole file extension handling and naming is simply messed up in the ecosystem, and it does not make sense to have imports from not existing files. But there are strong opinions, why tsc does not re-write import file names. Same for the whole *.mjs and *.cjs extensions.

yassinrais commented 4 months ago

Thanks for your feedback, @sebastianwessel. I'd like to clarify the specific issue I'm facing in my Expo (React Native) project with TypeScript.

In projects where TypeScript compiles to JavaScript, using .js in imports works because the .js files are actually generated. However, in React Native projects that use TypeScript, we don't typically see this .js generation step. The React Native environment allows us to use .ts and .js files interchangeably without an explicit compilation step.

The issue arises with the files generated by this library. Here's an example of the error I'm encountering:

iOS Bundling failed 17922ms node_modules/expo-router/entry.js (2766 modules)
Unable to resolve "./config/index.js" from "api/generated/client/index.ts"

This occurs because the library is generating import statements with .js extensions, but in our React Native setup, these .js files don't exist - we're working directly with .ts files.

To address this, could we make the import extension configurable? We could keep .js as the default for compatibility with projects that do generate .js files, but allow users to specify .ts for React Native projects where we work with TypeScript files directly.

This would improve the library's usability across different project setups. We could add documentation explaining when to use each option.

Does this approach sound reasonable? I'm open to discussing alternative solutions.

sebastianwessel commented 4 months ago

Ah ok. I'm thinking about to do it more generalized. Meaning the option is .js (including the dot + ext) and simply passing the extension value as string down the path. So, no if-clause in every file. Instead, simply +extString. This allows .js, which should be the default, .ts which covers your use case, and also empty string, which is handled properly by Bun & Co.

@hammo92 what do you think?

hammo92 commented 4 months ago

Ah ok. I'm thinking about to do it more generalized. Meaning the option is .js (including the dot + ext) and simply passing the extension value as string down the path. So, no if-clause in every file. Instead, simply +extString. This allows .js, which should be the default, .ts which covers your use case, and also empty string, which is handled properly by Bun & Co.

@hammo92 what do you think?

I think this is the right approach, cleaner code and more flexible.