Unused imports in generated InputObject modules about elm-graphql

[dillonkearns]

Hey @xtian, thanks for starting the discussion. I don't think I can commit to eliminating unused imports because it would increase the complexity of the code quite a bit. There may be some low hanging fruit to reduce a few cases but I don't think that eliminating them entirely is something that is likely to happen. The tradeoff of the code being more bug-prone and difficult to maintain would be a hard one to make.

Is there a reason that this important for you/your team? Could you elaborate a little on what your use case is for this? Do you use it in your CI build as a sort of linting process and fail if there are warnings?

[dillonkearns]

And of course if there were some nice automated tool to remove these I would gladly run it after the code generation, but unfortunately elm-format doesn't provide a flag or anything to do this (it was discussed briefly in avh4/elm-format#135). And I haven't seen any other tools to do this (besides some tools for the Atom editor).

[xtian]

Is there a reason that this important for you/your team? Could you elaborate a little on what your use case is for this? Do you use it in your CI build as a sort of linting process and fail if there are warnings?

We do have a CI check for unused imports, but we exclude the Api.* modules from it. This is mainly a development inconvenience since on a clean build the terminal is filled with several screens-worth of warnings from the generated modules. Ideally we would only see warnings from non-generated code so we could fix them.

[dillonkearns]

@xtian how do you exclude Api.* from the CI check? Could something similar be used for the dev environments? If it were me I would be using the exact same script on both to make sure that things are good in dev before I push.

[xtian]

@dillonkearns No, the warnings are from the Elm compiler. As far as I know there's no way to disable warnings there. The tool we use on CI is elm-analyse which has a config for ignored file paths.

[dillonkearns]

Ah, okay gotcha, thanks for clarifying. Again I don't think I can commit to this as the tradeoff for code maintainability and complexity would be pretty serious and there are some other higher priorities, but I will certainly keep this in mind.

[xtian]

Cool, thanks! Also, the idea of doing this as a second pass in some tool is interesting. I may look into implementing that.

[dillonkearns]

Yeah, that would definitely be ideal if some tool took care of it.

[dillonkearns]

If it's alright with you @xtian, I'll close this issue for now. I'll keep this in mind though and I'm more than happy to revisit this later.