Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generator: Incorrect File Extension in Imports for Generated Client #109

Open
maaaathis opened this issue May 31, 2024 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@maaaathis
Copy link
Contributor

Problem Description

The generated client currently includes .js file extensions in the imports of local files like the descriptors.js and types.js. This causes issues with frameworks like Next.js, which do not handle these imports correctly. As a result, users are forced to manually remove the .js extension from these imports.

Steps to Reproduce

  1. Generate the client using the provided tool.
  2. Notice that the imports of local files in the generated code include .js extensions.
  3. Attempt to use the generated client in a Next.js project.
  4. Observe the errors related to import paths with .js extensions.

Example

Here is an example of the problematic import statement:

import * as descriptors from "./descriptors.js";

This needs to be manually corrected to:

import * as descriptors from "./descriptors";

Proposed Solution

Update the client generation logic to omit the .js file extension in the imports of local files. This change should ensure compatibility with frameworks like Next.js and improve the overall usability of the generated client.

@maaaathis maaaathis added the enhancement New feature or request label May 31, 2024
@martin-helmich
Copy link
Member

I'm confused tbh., since I've never had any issues with this. Is this maybe some kind of ESM vs. CJS thing?

@maaaathis
Copy link
Contributor Author

I'm confused tbh., since I've never had any issues with this. Is this maybe some kind of ESM vs. CJS thing?

Yes, exactly. The .js endings in internal imports are usually required for ESM-based projects. But if you change the TypeScript moduleResolution to bundler (which Next.js does out-of-the-box) this is no longer required and even breaks the generated files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants