Older versions have been overwritten?

[JQuezada0]

It seems older versions of this package have been overwritten. I no longer see any output from the cli command (file or logs), and my usual script elm-typescript-interop src/Main.elm --output=_bundle/index.d.ts no longer seems to work, it just prints TODO. Is there any way to control the output directory of the types? And can the older versions be restored?

[dillonkearns]

Hello @JQuezada0! I've made some significant improvements to elm-typescript-interop and made it much more robust. Instead of passing in a list of files (before you had to pass in the path to each source file, and it would parse those files to get a list of all the type aliases you defined so that it could resolve them to figure out the type of your ports and flags. You then had to pass in a --output argument to tell it where to output the files.

As it turns out, the proper place to output TypeScript declaration files (.d.ts) is in ModuleName/index.d.ts (here's one place they mention this in the TypeScript docs). When you have the files outputted to this location, TypeScript is able to find it with zero configuration (no // reference pragmas or anything like that).

So that is the new behavior for elm-typescript-interop... It automatically outputs a file for each main : Program ... in your Elm modules, in a file named with the above technique. So when you run the script, it just works (this is one of the main goals of this library, it should just be able to read your Elm project and do the right thing automatically and with guaranteed correctness).

So now the CLI is much simpler. It doesn't accept arguments. You just run it from the directory with your elm.json or elm-package.json, and it will automatically parse the proper files, and output the .d.ts file to the correct location(s).

If for some reason you need to generate the .d.ts files in a different location, you can run a mv src/Main/index.d.ts _bundle/index.ts. But if you find yourself having to do that, then based on what I've read from the official TypeScript docs, I believe you probably have a non-standard setup that could be simplified.

It is a bug that it is outputting TODO. The reason for that is that I was running into some issues publishing a bug fix for the Elm 0.18 version of elm-cli-options-parser, which I use to ensure that valid CLI arguments are being passed in. The reason this is still using Elm 0.18 is because the elm-ast packages I depend on haven't been updated yet. Anyway, I'll leave this issue open to track fixing the incorrect CLI output when you pass in arguments.

Thanks!

-- Dillon

[JQuezada0]

Ah I understand, thanks for the explanation!

It turns out the reason it wasn't generating types for me was the lack of annotation. Might be good to add that somewhere in the readme to just make sure the main function has an annotation.

I do have an atypical setup, I'll use gulp to move things around.

[dillonkearns]

Ah yes, I hadn't considered that possibility, but that sounds really confusing indeed! Thank you for letting me know about that. I think it would make a lot of sense to give an error if any function named main does not have a type annotation 👍

I do have an atypical setup, I'll use gulp to move things around.

@birowsky was telling me he had an unusual setup as well, and was trying to find a clean way to use the generated .d.ts files. Maybe you can coordinate with him in the Elm Slack and compare notes. The #webpack channel might be a good place for that conversation. @ mention me if you have a discussion about it there!

[dillonkearns]

It is now giving an error if you have any main functions with no annotations. Here's the example from my end-to-end tests, and here's the error message you get.

I'll leave this open to track fixing that TODO message when you pass in CLI arguments.

Thanks!

[dillonkearns]

Alright, I've also fixed the TODO message issue (here are the 0.0.12 release notes). Thanks again for your feedback! Let me know if you run into any other issues.