Various bug fixes and improvements. #17
Conversation
...and exclude grandparents. The immediate parents are needed to make sure that we don't miss them when computing closures. The grandparents are not needed -- we'll get them through the immediate parents.
We just return the type of the parent. The rest will be taken care by `getParentTypes`.
Before this change, the following type
data Test = TestBlah {x :: Int, y :: Bool}
when configured with `tagSingleConstructors = True` would have generated
getTypeScriptType (Proxy @test) ==> "Test"
formatTSDeclarations (getTypeScriptDeclarations (Proxy @test)) ==>
interface TestBlah {x: Int, y: Bool}
That is, there would be a dangling references to a non-existent
interface `Test`.
This allows to have unions as keys, which often happens when encoding variants made out of nullary constructors.
There was a problem hiding this comment.
Thanks for the PR @bitonic ! Most of these changes look great.
However, I added a few tests to exercise the Maybe stuff better and there are some failures. I stuck a commit onto your branch here to demonstrate: https://github.com/codedownio/aeson-typescript/tree/francesco
These test failures aren't exactly your fault, it's more due to how this library hasn't properly handled omitNothingFields in the past and has always encoded Maybe using question marks even when T | null would be a better choice.
Any chance you'd be open to fixing those tests in this PR?
| @@ -93,12 +93,14 @@ data FormattingOptions = FormattingOptions | |||
| -- ^ Function applied to generated interface names | |||
| , typeNameModifier :: String -> String | |||
| -- ^ Function applied to generated type names | |||
| , exportTypes :: Bool | |||
There was a problem hiding this comment.
Could you add a documentation string here?
There was a problem hiding this comment.
Also curious about the need for this -- I always put my types in .d.ts files, is there some reason you want to put them in an ES6 module?
There was a problem hiding this comment.
I generate automatically not only the types, but also automatically generated code that builds a data structure that holds fetch invocations with the right request and response type, through https://github.com/bitonic/solga/tree/francesco/solga-typescript . I store the generated types alongside this definition, and therefore I need the exports.
|
@thomasjm thanks, I'll take a look at those soon. |
|
The latest commits look good @bitonic . I'd love to get this merged and get a new release out with these improvements. Are you planning to get the tests passing? Thanks! |
|
Working on integrating the remaining changes from this PR:
|
|
Okay, I think that's everything! I'll get a release out with all this stuff soon. Thanks again. |
No point having a default when the user cannot access to override it! This was forgotten in PR codedownio#22 when extracting it from PR codedownio#17.
…ixes. Our fixes: codedownio/aeson-typescript#17 The one that wasn't taken verbatim, which this commit adapts to: Upstremed in: codedownio/aeson-typescript#22 We still have to use our fork to fix `defaultFormattingOptions` not being exported: codedownio/aeson-typescript#27
I suggest to review commit-by-commit, they do one thing each and they should explain well what the fix is.
There are no tests yet -- I hope to get around to it soon.
This change is