-
-
Notifications
You must be signed in to change notification settings - Fork 27k
Typescript namespaces to be considered? #5633
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
Comments
You should be able to define these in a Can you co-locate these types next to the source file in a |
Well, I don't want to use |
|
Seems like the best path forward is to have |
That module supports custom generators I can write myself. However, I am not sure how it should look like. What do you mean by "modern type definitions"? |
If I understand correctly what you mean, the result should look like this? export type GLogoutWidgetVariables = {
id: string
}
export type GLogoutWidgetQuery = {
__typename?: 'Query'
user: User
}
export type GLogoutWidgetUser = {
__typename?: 'User'
id: string
firstName?: string | null
lastName?: string | null
} If that's what you mean then I don't like it at all because that's the same thing that |
Why couldn't you just |
That does not make much sense. These types are generated from all queries and put into single Ok, nevermind I guess. It's not worth spending time on this. I found related babel issue and it's apparent that namespace will never be part of that plugin because they are legacy . Oh well. I am so glad that |
@FredyC Try using -export namespace GLogoutWidget {
+export declare namespace GLogoutWidget { Let me know if that works for you. |
I'm sorry and understand that this is likely frustrating, but namespaces are a proprietary, legacy feature. They have been replaced by specification behavior: ES Modules. If this isn't satisfactory, you are free to continue using this feature until it is deprecated in TypeScript. You can try what @brunolemos recommended, but aside from that, we'll not be taking any action at present time. We've provided you with two solutions that work with our implementation, so I'm closing this as resolved. |
Seems like that should just about settle this issue. Either convince the Babel folks to support this, or shoot me a PR over at customize-cra adding the ts-loader, and removing the current Babel solution. |
@Timer As it was said a linked babel issue, I wasn't able to find any information about why are namespaces legacy. Later in that discussion, it's revealed that it's more of a technical issue than a problem of being deprecated. I can live what that, but let's not spread the false accusations here :) @brunolemos Thanks for the tip, but I've already switched back to TS fork and don't want to spend time on this anymore. It's kinda a shame. In a sense, I was looking into being able to tap into Babel world while using TypeScript without extra hassle, but this is too much blocker for me. |
After some initial bickering that Typescript support does not include this and that I've decided to give it a try. Unfortunately, I've stumbled upon a big obstacle.
I am using graphql-code-generator package to generate strong types for my GraphQL queries. In the essence, it generates types like this.
Usage of namespaces in this is extremely helpful as it clearly separates types for each query/mutation. Compared to
apollo-codegen
which outputs extremely long and annoying names for types, this is a clear win.I would like to know if namespace support is such a huge technical problem that it cannot be included. I mean when bundling the app it should be mostly about stripping type information and let the TypeScript worry about type checking. I am kinda lost why such a decision has been made to have a separate TypeScript parser that's limited like this.
/cc @Timer
The text was updated successfully, but these errors were encountered: