Why not contribute these checks back up to the compiler?

[cdeszaq]

Many of these checks jump out at me as being either dumb, obvious issues that should be fixed (eg. duplicate imports), or clear "this is a bad idea or has no real purpose" (eg. duplicate assignment). Rather than having these checks live in a separate package, the world would benefit more from the checks being run by the compiler.

Don't get be wrong, for less obvious or more contentious checks I can totally see the value in having these in a separate package, and the package can definitely move more quickly than the core language, so having elm-analyse hold the checks is fantastic, but what would it take to contribute back up-stream?

[stil4m]

I hope that one day, elm-analyse is obsolete. I would be happy if some of these checks are incorporated in the compiler, and I am willing and hoping to contribute to that process. However, at this moment in time, I do not want to actively push these things back to the core team, which is busy developing the language. I would like to have the community think about how they write Elm code, how we can do it better and evolve tooling around the language. The core team can then decide which things are important and adopt or re-implement this in a better way that supports the community. If elm-analyse (or parts of it) become a core-tool I would be a happy community member :).