Verify that examples missing "-->" still compile

[MartinSStewart]

I have documentation that looks like this

{-| Start creating a codec for a record.

    type alias Point =
        { x : Int
        , y : Int
        }

    pointCodec : Codec Point
    pointCodec =
        Codec.object Point
            -- Note that adding, removing, or reordering fields will prevent you from decoding any data you've previously encoded.
            |> Codec.field .x Codec.signedInt
            |> Codec.field .y Codec.signedInt
            |> Codec.finishObject

-}

There isn't any meaningful output to test against with "-->" but I would still like to verify that this code compiles.

Edit: And in this case I just noticed that I renamed signedInt so this is indeed invalid code. Having a way to check for this kind of stuff would be very useful!

[Orasund]

I second this. I would like to have my functions that return Html tested. In Particular, I do not care if it looks correct, just if it compiles.

[Orasund]

Found a workaround by adding

|> always "Ignore this line" --> "Ignore this line"

to the end of the code.

[gampleman]

I agree that this seems very handy!

How exactly do you propose this should work though? At the moment this tool generates code files that elm-test than picks up. But if a file doesn't expose a test, then I don't think elm-test will pick it up and compilation errors won't be surfaced. On the other hand, generating files with true |> Expect.equal true assertions just to do type checking is kinda gross...

[MartinSStewart]

Haven't used this tool in a while but

On the other hand, generating files with true |> Expect.equal true assertions just to do type checking is kinda gross...

doesn't seem so bad for generated code that I won't be interacting with?

Maybe I'm misremembering how this works though.

[gampleman]

doesn't seem so bad for generated code that I won't be interacting with?

Makes your tests run more slowly every time.

Maybe a more complicated scheme would just create one fake test, but import all the typechecking modules to include them in the typecheck. That way the runtime penalty is always O(1) and compile time penalty isn't too bad, since elm does pretty decent caching there.