prisma-labs/graphqlgen

graphqlgen issues

steida opened this issue · 5 comments

  1. .tsx files are ignored for some reason. .ts files work.
language: typescript

schema: ./schema.graphql
context: ./types.ts:Context
models:
  files:
    - ./types.ts

output: ./api/generated/graphqlgen.ts

resolver-scaffolding:
  output: ./api/generated/tmp-resolvers/
  layout: file-per-type
  1. IFoo naming does not work.

Interfaces should be prefixed with I (Hungarian notation). It's checked by tslint and IMHO it is a good rule. It prevents naming clashes. Foo vs IFoo.

screenshot 2018-12-18 at 00 00 08

Therefore, we have to tslint ignore it.

Also, please handle unused. TypeScript --strict is a good thing.

screenshot 2018-12-18 at 00 42 17

Regarding unused variables... Just prefix with _. Besides that, what should be handled? The variable has to be there and I don't see the semantic way to get rid of the variable without confusing people who need parent. I'd actually say that the fourth variable info should be included as well. We might talk about prefixing the variables with _, in order to satisfy linters, but I've not had a personal problem with this so far and I have all the rules I can get, including unused variables.

TSlint has a bunch of rules, some are opinionated and they are extremely easy to change. It seems you haven't done anything to your rules and if so, you are keeping some opinionated ones which aren't applicable to everyone and every app. It's pure opinion, I won't say what's right or wrong, but prefixing interfaces with I and never have undeclared variables are nothing but opinions. Things shouldn't be changed because of a default rule.

Now, the reason I'm arguing this much is your very demanding & demeaning tone - while all that's happening is some linting rules that you have set on/not touched. And you're not arguing in any way, it's just demanding and stating that people should use --strict, as it's a good thing. That's just not a nice way to speak to others.

I don't know why you would want to use .tsx files to declare resolvers. Resolvers aren't using JSX or React.

_ prefix is a good workaround, thank you.

I carefully revied TSLint default settings. Interfaces prefixed with I are useful (because of clashes) and very common. --strict is really recommended, especially for beginners. Any check helps.

As for .tsx, it's common to use the same suffix everywhere and React is not only for components.

No problem, I had to search on and off for 2 months before finding it.

Regarding the I prefix (where I completely agree with the rule itself and use it all the time), I don't think it's necessary to prefix these interface names, as they are quite verbose and it would be annoying to e. forget to type "I" every time I have to search for my inputs.

My main point is that the generated types are verbose enough to not conflict with existing types from frameworks. They are graphql & query/subscription/mutation related, which makes the naming quite a lot different from any other types I've seen or wanted to name. I actually had to get used to this way of naming the queries and have changed my own conventions to follow those made by the generator a lot more as I really like it.

My workaround so far has been to disable ts-lint in my generated folder.

I'm still not sure why you'd want to use JSX in these kinds of files, it should be possible, as the same code would work in either extension, but I don't have a good reason as to why. I find that it's nice to be able to tell my JS(TS) and JSX(TSX) apart when having to deal with renaming, moving or organize files in my JSX projects.

I do not disagree that React isn't just for components and if you have a usecase for using React for other than components, I've experienced something new. Other than that, .tsx or .jsx files are just for using JSX.

ok