Type inference difference between Elm.ToString.* and Elm.file

[tesk9]

trafficstars

Using generated package code for rtfeldman/elm-css works when using Elm.ToString helpers, but not when using Elm.file.

When using Elm.file, Gen.Css.marginRight (Gen.Css.px 1) will cause an error like ELM-CODEGEN ERROR -- I found Css.LengthOrAuto compatible_0 But I was expecting: Css.Px

I believe this is because elm-css does some type-trickery in order to allow helpers that take "different" units, like pct, px, etc. A Css.Px is a ExplicitLength, which is a Css.LengthOrAuto.

Ellie example illustrating the problem when using Elm.file

---

Should users only use file if they're working with generated code that results from Generate.elm, rather than using Gen.* directly?

[mdgriffith]

Oo, yeah, hmm. Definitely these types of type tricks are the hardest for elm-codegen to resolve.

There is a workaround, you can add Elm.withType to skip what the inference thinks and just have it generate what you want. You can also construct an Annotation to use with Elm.withType by using the values in Gen.Css.annotation_

So, I think that would be |> Elm.withType Gen.Css.annotation_.px

Users should be totally Ok to use file if they're working with the Gen.* stuff, I just need to figure out what's going on, type-inference wise.

Thank you for the Ellie allows me to put that into my tests for this kind of thing.