notquiteamonad / tie Goto Github PK

The project should be fully documented using haddock to make it easier for new contributors.

I propose that it makes sense to do these one module at a time since none of the modules are very large, so here's the list:

• TIE.Elm.Internal.Expression
• TIE.Elm.Expression
• TIE.Elm.Init
• TIE.Elm.Ports
• TIE.Elm.Types
• TIE.FS
• TIE.Lib
• TIE.Response
• TIE.TypeScript

Test the case where the type of flags is a custom record type, one of whose components is another custom record type

Currently, given an elm record type:

type alias User =
  { uid: String
  , email: Maybe String
  }

the resultant DTS will be

export interface User {
  uid: string;
  email: string | void | null;
}

This doesn't actually allow the parameters to be omitted, as the void was intended to do. Instead, the following DTS should be generated:

export interface User {
  uid: string;
  email?: string | null;
}

Currently, to use the npm package with Yarn 2, the dependency needs to be unplugged or the binary is not found. If we can find a way to find it without unplugging that'd be preferable.

Failing test case:

type alias MyAlias =
    String

There are some small steps we could take such as showing errors in red which could make a big difference to readability and usefulness of them.

For example, a Japanese company may wish to use Japanese characters in an identifier. AFAIK this is allowed by Elm. It might be worth hiding this behind a flag, though, for performance reasons

• README
• LICENSE
• CONTRIBUTING etc (see samueldple/date_time)
• CHANGELOG
• Obsidian

Note: This issue refers to high-level documentation. For haddock documentation see #22

TIE does not currently support windows. Attempts to build for Windows in GitHub actions have so far failed due to a lack of the ncurses dependency. Since ncurses is for linux, I expect this is related to the use of safe-coloured-text. Therefore, I expect that a separate stack executable will be needed for Windows without that dependency.

Then again, I haven't used Windows in years and could be completely wrong, so if anyone with a bit more knowledge on this would like to help out it'd be greatly appreciated 😅

Currently it only regenerates on changes to .elm files.

It would be nice to test TIE with a large Elm project and see if there are any small changes we can make to improve performance. I'm fairly new to Haskell so there could be some obvious ones a more experienced Haskeller would spot right away.

Null must be passed explicitly, so the type definitions generated for Maybes allow the invalid void type. This should be removed.

Currently it'll flag it as an error and stop the run. However, on cross-os teams this might cause issues, so it should warn but not fail.

Use </> from System.FilePath

There's no need to keep going char by char are that point

Elm supports passing Tuple values such as (1, "Hello") through ports, but TIE doesn't recognise tuple types. We should add support.

If we can support mac through a binary releaase that'd be preferable for users. I don't have the machines or knowledge to build or test on, though, so I'll need some help from the community for this.

https://blog.woubuc.be/post/publishing-rust-binary-on-npm/

On an incoming port, it is sometimes desirable to take a string which will be converted to a sum type in Elm. Currently, TIE's generated definition will just be string for this case, but it would be nice if we could tell it to use something else such as "success" | "error"