gbtb / elm-gen Goto Github PK

By default npm installs 0.1.1 version, while 0.1.3 already exists and pushed into npm repo(and can even be installed by manually adding @0.1.3).

While it should be possible to specify source dir as an arg, I can use sourceDir from elm.json. Especially with this oficial package - https://package.elm-lang.org/packages/elm/project-metadata-utils

• Fix array and list
• Add set and dict encoders into usage

• Expand Readme and examples
• Document public api functions
• Consider usage of runtime exceptions in fromJust (maybe it is not that painfull to wrap code up into Result's and Maybe's?)
• Perform overall architectural cleanup/refactoring to ease understanding, properly split up functions and so on...

Every now and then I use hardcoded JE and JD aliases, which is wrong. It should be configurable.

I.e dont include Decode.Pipeline into Encoders file, etc.

Some of the features for union type generation, was already added to config, but not implemented in reality.
type UnionTypeGeneratorFeature = TrivialString | TrivialObject | DefaultConstructor

It has two major parts:

• Ensure no breaking changes in json libs/syntax happend (maybe it will require addition of an elm-version config field/arg)
• Transfer whole project into 0.19. Major block here is elm-ast, which relies on custom parser lib, which heaily uses custom bin ops, which will be deprecated in 0.19 :D.

For now elm-gen cant generate decoder for this:
type alias A = List T

Explicit type alias declaration ruins records structural typing ability. So, we need an option in a config, as well as meta-comment for that.

Impl Online demo-site, with simple one-file generation case could be fun and not so hard to develop.

Fast enough i have met a pretty simple usecase, in which current type name handling in library - single plain string - doesn't allow code generation. This problem affects whole library, but could probably be solved separately on per-usecase basis.

• Allow provide decoders for namespaced types - e.g. Dict.Dict, Material.Model.
• More stuff to come, I suppose.

Nested record declaration causes error:
Not allowed type in recordField

elm-gen e src/ConvertableTypes.elm ./src
results in incorrect module declaration -
module src.ConvertableTypesEncoders exposing (..)

I found, that its actually imposible to successfully provide a custom decoder for Dict.Dict kind of type (with type variables).

• Fix this test case
• Look into general approach for generating decoders for types with type variables