Graphql-code-generator: Namespaces are legacy according to Babel?

[FredyC]

Well, this is a long shot, but I want to kinda discuss here the issue that has been raised in ReactJS world. The gist of it is that there is a Typescript implementation coming from Babel team and it's somewhat limited for a various reasons. The most notable is that namespaces are not supported.

Now in that React issue there is some mention of "ES modules" that are cool & better variant. So I am wondering where is the truth. I got kinda used to how graphql-code-generator works and I happy with it. However, I would not like to lock myself out from a future stuff.

I am aware that this could be solved by custom generator, but honestly, my TypeScript knowledge is limited on this subject and I am not sure how it should look like to have similar quality approach a with namespaces.

I was thinking about some slighly different approach and I am not sure if GCG is able to that. Instead of a single file with all types if there could be a separate file per each source file with a generated types which would references a shared file with inputs/enums.

[dotansimha]

Hi @FredyC !
At the moment, we do have a noNamespaces flag for the TypeScript resolver, that generated typings without namespaces at all.
I think we might change it to be the default behaviour, because it seems that TypeScript namespaces becomes obsolete.

[890f2151c2be69c51db72017546d00fd]

I think we might change it to be the default behaviour, because it seems that TypeScript namespaces becomes obsolete.

it would be great because react create app 2 now support typescript but without namespaces.
or add --noNamespaces as CLI option

[desbrowne]

It would be great to use modules instead of namespaces (i.e. one file for each query), but I have seen that MULTIPLE_FILES seems to be depreciated. @dotansimha wondering if you have an recommendation of how to achieve this?

[ardatan]

I think this may cause circular imports problem which would be really hard to maintain. For now, TypeScript's own React/JSX Compiler can be used with Webpack instead of dealing with Babel-TypeScript limitations; because TypeScript's namespace syntax is not deprecated or obsolete but only Babel-TS has problems. While there is an option noNamespaces as a workaround, I don't think we should change the default behaviour; because this package is for all TypeScript users not only Babel-TypeScript.

[FredyC]

I've kinda given up on Babel-TypeScript solution, it doesn't feel like it's worth a hassle at this moment. It's good to know there is a noNamespaces option, but I don't like the output it makes really. As I said in the issue I like the approach that I can import a namespace and reference other types inside of it instead of being forced to import one item separately or a _full package_. It's some really stupid idea to make namespaces obsolete, not sure who decided that :(

[vko-online]

@FredyC namespaces are good when using in multiple files, but babel says --1-file-at-a-time--. So they just are different