Summary

I would like to have the ability to write FFI modules in TypeScript (TS) rather than JS. It's true that this would already be possible by first compiling TS->JS for FFI before Purescript runs, but I think it would be useful to have first-class support for this.

I don't expect the Purs compiler to transpile this to JS - for my use case I feed the output/ into esbuild with other TS files later in my build pipeline, and the transpilation is done then. So for my use case, having .ts files under output/ is acceptable.
For backend code, native TS is already supported by the main runtimes (Node, Deno, Bun).

I think this would be an improvement over having to run tsc on my FFI modules each time before purs compile.

Motivation

Writing FFI in pure JS means my IDE isn't as useful as it could be when working on these FFI files. I can write JSDoc comments, but when I already have other TS code in my codebase, this is unnecessary extra mental overhead to switch between the different syntaxes - and in my opinion TS is far more ergonomic to write.

Proposal

There was a brief discussion about this on Discord.

The main question I have at this point is how to handle the case of parsing FFI module files for the purposes of detecting exports.
This currently uses language-javascript which does not support typescript.
There was already some discussion in #4227 about removing/replacing this - seems like a similar problem here.

As far as I can see right now we either:

1. skip this check for TS files and rely on a later build step such as esbuild to verify it, else leave it to be a runtime error in the case of native TS execution
2. delegate this to some external TS parser tool (tsc? @typescript-eslint/parser?)
3. implement and maintain!! a Haskell TS parser ourselves 😟

@natefaubion suggested that the best approach to this may be to add a compiler option to support non-js file extensions (this could also be useful for people using JSX, for example)
This could be similar to -g,--codegen ARG where it's a comma-separated list of extensions to consider for FFI modules, defaulting to js.

We'd have to consider the case of there being multiple FFI modules present for a single Purs module matching the provided extensions. I'd say this should probably be an error - I can't think of a case where you'd genuinely want to do this?

Legit question from @hdgarrood on #4227 is that without parsing JS/TS files we'd lose the current functionality that flags unused exports from the FFI module. Perhaps this responsibility may be better served by another tool, but removing it would be a regression from the current behaviour.

Examples

1. Compiling with current/no flags = no change, only .js files are considered as FFI modules, existing behaviour is retained
2. Providing new flag (eg --ffi-exts js,ts) = consider both ts and js files for FFI modules. For ts files, exports are not validated - that's left up to the bundler or runtime. If files with >1 provided extension are present, throw a compiler error.