The README suggests defining instances related to LangTS and LangTSDecls but these types are not exposed

[exarkun]

The "Supporting additional combinators" section gives these examples:

instance HasForeign LangTS Text WebSocket where
    type Foreign Text WebSocket = Text
    foreignFor _ _ _ _ = "void"

instance HasForeign LangTSDecls [TSDeclaration] WebSocket where
    type Foreign [TSDeclaration] WebSocket = [TSDeclaration]
    foreignFor _ _ _ _ = []

However, LangTS and LangTSDecls are defined in Servant.TypeScript.Types which is not exposed, and they are not re-exported from any exposed module. As a result, support for additional combinators cannot actually be implemented.

[thomasjm]

Okay, I exposed those and got the CI green again as of 6110b7a.

Does that solve things for you? Let me know and if so I'll make a Hackage release.

[exarkun]

Thanks. Those changes let me write the instances I thought I would need to write. I still haven't managed to generate any output for the non-trivial parts of my API so I'm not sure that I'm on the right track - so I don't know for sure yet whether or not those instances are actually useful to the eventual goal (but it seems like they should be).

[thomasjm]

Okay, let me know if I can help, I'm interested in seeing if this library is useful to people.

I have some other code I've been meaning to move into this library as well, for generating APIs which use servant-checked-exceptions.

[exarkun]

Two other things I've bumped into are support for custom request header values (eg for authentication) and handling Servant's UVerb combinator. I've done a little work towards addressing the former (just PoC-grade code so far). I'm not sure what to do about UVerb. If you like I can file other issues with more details.

At this point, I have gotten some TypeScript code generated using the newly exposed LangTS and LangTSDecls so I think the changes you made related to this issue are probably good. I did wonder briefly whether instances of this form might be sufficient:

  instance (HasForeign lang Text api) => HasForeign lang Text (TokenAuth :> api) where
    ...

and maybe they are sometimes but it seems like generating correct output most often need a more precise instance head that involves LangTS or LangTSDecls.

[thomasjm]

FWIW, when I have some random combinator that doesn't affect the foreign code generation, I do something like the following. This is for the SessionRefresh combinator I defined, which updates auth cookies when they're expired. This is sort of a blanket "skip over this combinator when doing foreign code stuff," so with this I don't even need to define instances for LangTS or LangTSDecls specifically.

instance (HasForeign lang ftype sublayout) => HasForeign lang ftype (SessionRefresh :> sublayout) where
  type Foreign ftype (SessionRefresh :> sublayout) = Foreign ftype sublayout
  foreignFor lang pf _ = foreignFor lang pf (Proxy :: Proxy sublayout)

[thomasjm]

Btw it looks like UVerb definitely does affect the foreign code handling, and will need to be handled similarly to the servant-checked-exceptions stuff.