interfaceNameModifier applied to tail of interface name not whole interface name, triggers name format error for valid interface names

[Dridus]

interfaceNameModifier is documented as "Function applied to generate interface names" and so I'd expect it to apply to the whole interface name, but the call to it for TSInterfaceDeclaration splits off the first character and applies the function to the tail:

      modifiedInterfaceName = (\(li, name) -> li <> interfaceNameModifier name) . splitAt 1 $ interfaceName

(https://github.com/codedownio/aeson-typescript/blob/v0.6.3.0/src/Data/Aeson/TypeScript/Formatting.hs#L60)

this is especially awkward since 0.5.0.0 when the default formatting options were changed such that names are validated as valid typescript identifiers; that validation expects the full identifier, and so fails if the second character isn't a valid first identifier character:

import Data.Aeson.TypeScript.TH
import Data.Aeson.TypeScript.Internal

let decl = TSInterfaceDeclaration "A1" [] [] Nothing
formatTSDeclaration defaultFormattingOptions decl

⇒

"interface A*** Exception: The name 1 contains illegal characters: 1
Consider setting a default name formatter that replaces these characters, or renaming the type.
CallStack (from HasCallStack):
  error, called at src/Data/Aeson/TypeScript/Types.hs:157:11 in aeson-typescript-0.6.0.0-HYYVUss2s6t2E3z9zSEOcD:Data.Aeson.TypeScript.Types

(https://github.com/codedownio/aeson-typescript/blob/v0.6.3.0/src/Data/Aeson/TypeScript/LegalName.hs#L12-L39)
(#35)

[thomasjm]

Hi @Dridus, I was thinking about what to do about this. #45 is a breaking change, so I'm not too inclined to merge it unless/until we have some other breaking changes to go with it.

Your problem is really that you're using Data.Aeson.TypeScript.Internal to construct your own TSInterfaceDeclaration that doesn't follows the "rules" of the rest of the formatting code (i.e. interfaces must begin with an "I"). The formatting code is a bit opinionated about this but it all works together nicely if you don't go reaching for the internal modules.

I realize it's sometimes useful to construct your own TSDeclarations. One idea that might help is to use the TSRawDeclaration constructor, which was added to allow you to inject arbitrary stuff into your generated TS.