Project Brief
Discord Post
Other requirements -
For releasing, testing and everything, it was one of the requirements that the repository is maintainable. That is of course a very broad term. I think this means, having some form of CI/CD setup, like; gh-actions testing on PR against main, automatically running release workflows based on version increases. I really like what I did for feliz by using Maximes
EasyBuild.PackageReleaseNotes.Tasks, which parses the version for an fsproj from a neighbour CHANGELOG.md file (only one source of truth). Then I created a .sln file that references only the projects I actually want to publish and always pack this file, then just release everything with--skip-duplicate. But if you have other preferences go for it. It would just be required that you document all available CI workflows and the steps they do.
Plan
The first consideration was where to create the bindings from.
We want it to be easy to maintain.
The first thing I consider to be categorically not easy to maintain, are bindings which are manually rolled. I, personally, have an exorbitant amount of technical debt in this already.
This is especially true in a package such as Electron which has such a significant code base.
Discovery
Committing to discovery, I considered what has been done before, and what the costs would be associated.
Previous community work that was done on Fable.Electron demonstrated an initial cost of manually rolling the bindings, and then subscribing to changelogs and updating the bindings as they come out (via a combination of the Docs & Source code).
Currently, the docs do seem very exhaustive. And spectacularly, they are also generated from a shared source of tested truth; their electron-api which was generated in several formats - such as the .d.ts (for user consumption), AND electron-api.json.
Each release included one of such files, that contained the information used to generate the docs in a more structured format.
This is perfect. The current plan would be to
Map the JSON to F# types
Create a library which first parses the JSON to a collection of type objects, or directly to a tool such as Glutinum for generation.
If not using glutinum, then caching, sorting, and generating names from the objects
Allowing some simplistic user-code to modify the types as required
Generate the bindings from those types using Fantomas.
From this, we can generate a workflow which would automatically regenerate, bind, and release Electron bindings.
Extensive testing would identify where there might be an issue that either
Has to be manually addressed in the user-code portion
Results in the parsed types needing to be adjusted
Results in the tests being adjusted
Task
Create the type map for the JSON api schema
Notes
It appears the API doesn't have a formal schema (at least that I've been able to find). That seems counter intuitive, and I might just need to look outside of a 'json' schema, and look instead for the definition in JS/TS source code.
Either way, it appears that we can still produce the source from the api, but we would have to clearly document the methodology so that any changes to the api structure can be easily matched in the source and then reflected in the bindings.