Should I remove the fsi files?
MangelMaxime opened this issue · comments
When writing Fable.Form I discovered the .fsi file feature of F#
I liked the fact that it made everything private by default, however I am wondering if this not confusing potential readers/contributors
It also makes the code navigation less friendly
Should I remove them?
I have mixed feelings about .fsi files. To be honest, Fable.Form is the first project I ever saw them in, so it was very confusing at first.
It took only one read at the official documentation to understand their place, and now I think they can be useful. That said... I think they add unnecessary complexity and adoption is low (F# adoption in general is low, fsi is even lower), so it's confusing to new readers.
FSharp.Core does use .fsi too for example, but I had the same problem as you when reading FSharp.Core repository.
I was like, why do then rewrite the almost the same code twice both in List.fs and List.fsi.
TBH, I will remove them from Fable.Form packages.
One of the benefit of .fsi files is that IDEs are more performant in general if you have them, because FCS can avoid doing some operation. However, Fable.Form repository itself isn't that big and so having or not the .fsi file for this reason should not have a major impact.
Use F# signature files (tooling performance)
Do you have an unavoidably large project? If so, consider using F# signature files (.fsi) for each implementation file (.fs).
The F# compiler will now actively not typecheck several things in a tooling scenario if you have explicit signature files:
- If you're editing a source file but you don't change the matching signature file, then only that file will get typechecked in tools. Nothing else that could depend on it will be typechecked while editing code.
- For modules/types/etc. you depend on when you are editing code (that are in your project), if the signature files for those constructs remain unchanged while editing, their signature data will be re-used and nothing "above" where you're at (from a dependency perspective) will be re-typechecked.
What this means when editing code is that all tooling should be significantly snappier for a large project with a lot of code.
Got it, I think I now understand the goal of fsi files... which makes me very nervous also, because one of our projects is growing in complexity (and codebase) and Ionide seems to take a dive often. I now fear the solution (eventually) will be littering our project with fsi files 😭