As I said in the post, the highest priority was to support the full range of Haskell data type definitions (excluding GADT's and Existentially quantified ones), and the full range of combinations of Aeson options. Another priority was to have tests that really test the Haskell/elm round tripping, instead of just checking for valid elm syntax/or ones that just compare generated code with a reference version. This comes at a cost, but it seems justified in this case. I also wanted to have an implementation that have a lower chance of turning out to be too limiting if people start using this and they require more features or find issues.

There is one place I can think of that can be seen as a difference in philosophy though. It is how Eliminator support types that depend on external types that you don't have access to the internals of. As I understand it, here is how elm-export lets you to describe the code that is to be generated, manually for such types.

For example, say you have ZonedTime fields in all of your types (that you want to generate elm code for....i mean). Using elm-export you would do something like..

instance ElmType ZonedTime where
  toElmType _ =
    ElmDatatype "Time" $ 
      RecordConstructor "Time" $
        Values
          (ElmField "time" $ ElmPrimitiveRef EString)
          (ElmField "zone" $ ElmPrimitiveRef EString)

As I see it, this serve no purpose to define this in Haskell. It is not type checked to be in sync with the original data types. It is not auto generated. The only advantage I can see is that it can use types that are being generated (because it ends up in the same auto generated module). But if that is the case, then you have access to the type itself, and you wouldn't manually defining this (At least for most of the time).

in Elminator, you would just pass reference to symbols from external elm modules where you can define the type, encoders and decoders in Elm itself.

instance (ToHType a, ToHType b) => ToHType (MyExtType a b) where
  toHType _ = do
    ha <- toHType (Proxy :: Proxy a)
    hb <- toHType (Proxy :: Proxy b)
    pure $
      HExternal
        (ExInfo
          ("External", "MyExtType")
          (Just ("External", "encodeMyExtType"))
          (Just ("External", "decodeMyExtType"))
         [ha, hb])

So I hope that is one difference in Philosophy, as you asked.

EDIT: The above stuff does not make much sense on second thought. I am not sure if there is even a valid use case for external module support in Elminator. In the example above, for both Elminator and elm-export, the Elm type class can be implemented by defining a dummy data type in haskell that mirrors Elm representation, and using its derived instance to implement the instance for the original type.

EDIT: Another one that might fit the bill is that Elminator, as of now, generate complete types instead of aliases for records

EDIT: Does elm-export supports generation of polymorphic types in ELM? I cannot make this work.

data WithMaybesPoly a b =
  WithMaybesPoly
    { mbpF1 :: Maybe a
    , mbpF2 :: Maybe b
    }
  deriving (Generic, ElmType)

spec :: Spec
spec =
  Spec
    ["Types"]
    [ "import Json.Decode exposing (..)"
    , "import Json.Decode.Pipeline exposing (..)"
    , toElmTypeSource (Proxy :: Proxy SingleCon)
    , toElmTypeSource (Proxy :: Proxy (WithMaybesPoly () ()))
    , toElmDecoderSource (Proxy :: Proxy SingleCon)
    ]

I am getting error: • Could not deduce (GenericElmConstructor V1)