Allow to export types easily #22
Conversation
src/Data/Aeson/TypeScript/Types.hs
Outdated
| @@ -98,13 +98,16 @@ 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.
In general this PR sounds good to me. I'm wondering if we should reduce boolean blindness / provide for future extensibility by making this data type though. Are there any other kinds of exporting someone might want to do? I know that there's some fancy stuff here like export default, export =, export as namespace... none of them seem very likely to be desired but it would be good to be safe.
There was a problem hiding this comment.
Wow, that was fast :) Thanks a lot for the quick review.
export default=> I personally don't have a use case for this, but it might be useful in some cases. Introducing a "default type" might require a bit more work API-wise. I guess we should expose a way for the user to tell whichNameis supposed to be the default one. I'm not really willing to implement this for now.export as namespace=> Could be used to nest the "module name". iemodule.namespace.typeinstead ofmodule.type. It might be useful in some niche cases, I personally don't have any use for this, I'm not sure whether or not we should implement that. I'll let your be the judge here.export = TYPE=> It's basically a synonym ofexport TYPE = (...)
I'm wondering if we should reduce boolean blindness / provide for future extensibility by making this data type though.
I'm not sure I understand what you mean here. Something the lines of:
newtype ExportTypes = ExportTypes Bool
newtype ExportInterfaces = ExportInterfaces Bool
data ExportOptions = ExportOptions ExportTypes ExportInterfaces?
There was a problem hiding this comment.
I was just thinking something like
data ExportMode =
ExportEach
-- ^ Prefix every declaration with the "export" keyword (suitable for putting in a TypeScripe module)
| ExportNone
-- ^ No exporting (suitable for putting in a .d.ts file)that way we can add more constructors if we want to someday
|
My apologies for the delay, I missed the notification. |
src/Data/Aeson/TypeScript/Types.hs
Outdated
| data FormattingOptions = FormattingOptions | ||
| { numIndentSpaces :: Int | ||
| -- ^ How many spaces to indent TypeScript blocks | ||
| , interfaceNameModifier :: String -> String | ||
| -- ^ Function applied to generated interface names | ||
| , typeNameModifier :: String -> String | ||
| -- ^ Function applied to generated type names | ||
| , exportTypes :: ExportMode |
There was a problem hiding this comment.
Thanks, could you just rename this to exportMode? Otherwise LGTM.
picnoir
force-pushed
the
nin-export
branch
2 times, most recently
from
6778282 to
336ccc8
Compare
| #{ls} | ||
| }|] where ls = T.intercalate "\n" $ fmap T.pack [(replicate numIndentSpaces ' ') <> formatTSField member <> ";"| member <- members] | ||
| modifiedInterfaceName = (\(li, name) -> li <> interfaceNameModifier name) . splitAt 1 $ interfaceName | ||
|
|
||
| formatTSDeclaration (FormattingOptions {..}) (TSRawDeclaration text) = text | ||
|
|
||
| exportPrefix :: ExportMode -> String | ||
| exportPrefix em = |
There was a problem hiding this comment.
Oh one more nit, sorry -- could you convert this case statement to a pattern match? i.e.
exportPrefix ExportEach = "export "
exportPrefix ExportNone = ""
In some cases, we'd like to use the generated types in a typescript module instead of a declaration file. When used in a module, the types need to be explicitely exported to be re-used elsewhere. Adding a new exportTypes FormattingOption in charge of prefixing the generated types with "export".
|
Perfect, thanks! Merging now |
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
Hi!
I'd need to generate some types for a typescript module, however, there's currently no way to export the generated types.
#17, added this feature, however, the PR seems to have stalled by now. This PR is just a cherry pick of 13822f0 rebased on the current master. I took the liberty to add a tiny bit of documentation.