You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This isn't really in a usable state, but my thought was that it should
not be necessary to try and re-implement the AST of TypeScript types.
In stead we should be able to pull out the representation as defined
by the typescript/lib module (which ts-morph wraps). Now,
unfortunately ts-morph is infected with OOP and so the structures
are circular and cannot directly be serialized. So a little logic is required to flatten the data.[see footnote 1] This is what I've tried to do.
My implementation uses unsafe coercions in two places. I'm not very
happy with this.
Below is an example of how the exported representation will differ
with this patch. Note that this will break your Haskell package
which is not expecting this structure.
One things that would need a bit of extra work is to convert the returnType field into something more structured. Really it's a Type node and does have a well-defined structure - but for some
reason when it's converted to JSON only a string representation is
output.
My implementation uses unsafe coercions in two places. I'm not very
happy with this.
TypeScript I wouldn't worry too much unless this becomes the norm
Note that this will break your Haskell package which is not expecting this structure.
That shouldn't be a problem at all. There's nothing set in stone yet, I'm just experiment around to be honest.
I guess is only a matter of finding the spec or some doces (there should be) around the TS AST to use it on the Haskell side.
The initial reasoning behind having our own representation was to have control on how it looked and only include what was needed. Thing is, eventually most of the AST will be used so I see now that it makes sense to just use that, if it turns to be inefficient it can be changed.
I meant efficiency in terms of consuming the AST on the Haskell side.
My plan for the initial iterations (until results are meaningful at least) is to us a small subset of libraries (probably the FP ecosystem https://gcanti.github.io/fp-ts/ecosystem/). So the output wouldn't be that big, but yes eventually some binary format would be better.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This isn't really in a usable state, but my thought was that it should
not be necessary to try and re-implement the AST of TypeScript types.
In stead we should be able to pull out the representation as defined
by the
typescript/libmodule (whichts-morphwraps). Now,unfortunately
ts-morphis infected with OOP and so the structuresare circular and cannot directly be serialized. So a little logic
is required to flatten the data.[see footnote 1] This is what I've tried to do.
My implementation uses unsafe coercions in two places. I'm not very
happy with this.
Below is an example of how the exported representation will differ
with this patch. Note that this will break your Haskell package
which is not expecting this structure.
One things that would need a bit of extra work is to convert the
returnTypefield into something more structured. Really it's aTypenode and does have a well-defined structure - but for somereason when it's converted to JSON only a string representation is
output.
Before:
After:
[1]: Alternatively some function that I have yet to find allows for exporting the structure whole-sale.