Making authoring Fable packages easier

[baronfel]

I was wondering if it might make sense to do some things to make authoring a 'Fable project' easier. Some ideas might be:

• authoring an MSBuild SDK for fable and extending the Build target so that dotnet build on a Fable project invokes dotnet fable .... to create JS artifacts?
• getting Source Files into NuGet packages not with explicit file includes, but by reading source files from the PDB of a published library when EmbedAllSources is true in the project file
• ???

[MangelMaxime]

I have a hard time understanding what you call "authoring Fable packages"?

Is this the process of publishing a Fable binding or libraries to NuGet. For example, Fable.Core, Fable.Browser.Dom, Thoth.Json ?

• authoring an MSBuild SDK for fable and extending the Build target so that dotnet build on a Fable project invokes dotnet fable .... to create JS artifacts?

If you are speaking about publishing Fable binding or libraries to NuGet, we don't invoke dotnet fable. You should never published the generated JavaScript files in the library.

If you are speaking about consuming Fable from the end user, I find CLI much easier to read / use, control via build system that MSBuild instruction. For example, how would you trigger/control the watch target?

• getting Source Files into NuGet packages not with explicit file includes, but by reading source files from the PDB of a published library when EmbedAllSources is true in the project file

We are not including only the F# files into the NuGet packages but sometimes we also include some JavaScript, CSS or JSON files too. Which are probably not included in the EmbedAllSources is true information that you speak about.

[baronfel]

That's all completely fair! This came out of a discussion on the FSSF Slack where someone was asking about a particular package and if it supported Fable, and I was thinking about what library authors have to do to support Fable. It'd be great if the only thing an author had to do was <EmbedAllSources>true</EmbedAllSources> for example, and then the fable compiler would know to extract the source files from the PDB and use those as the compilation inputs. I believe it's also fairly easy to add arbitrary other files to the PDBs in a similar way, to cover the question of CSS/Json/JS files, etc.

The MSBuild SDK question was more coming from a place of 'how much work is it to make dotnet build or dotnet watch Just Work :TM: for Fable projects'? If dotnet build worked, then you get watch for free by extension (especially if all of the miscellaneous files are added to the project file in <Watch Include="..." /> items as well).

[alfonsogarciacaro]

Thanks a lot for the suggestion @baronfel! I'm open for improvements in this are though, tbh, everything related to .fsproj, packages, etc. is something that's more or less working now and I'm afraid to touch because my knowledge of MSBuild is limited. Some notes:

• As @MangelMaxime says, Fable-compatible Nuget packages don't include the JS files generated by Fable (can include other JS files though). Fable compiles all sources from all packages together with the user's files. This is because it's not guaranteed the generated JS code is compatible between different Fable versions, so we need to make sure everything is compiled with the same Fable version.
• If it's possible to easily retrieve the sources with EmbedAllSources I would be open for a contribution (though this means we'd need to support both ways unless we want to break all existing packages), but there are two conditions that must be fulfilled:
  • Files must kept the same directory structure. This is important for import resolution, particularly when including native JS code (or other resources like CSS).
  • We also need to know the file order. For this we currently parse the .fsproj file included in the package. Not sure if the .fsproj is also included in the PDB.
• I understand that adding the <Content Include="*.fsproj; **\*.fs; **\*.fsi" PackagePath="fable\" /> line to the .fsproj may look complex because some IDEs make it difficult to edit the .fsproj manually. But for me the difficult part of authoring a Fable package is making sure the code is Fable-compatible (it only uses supported APIs from the BCL, it only depends on Fable-compatible libraries, etc). I'd try to avoid sending the message that, with a change like this, a package can be automatically made Fable-compatible just by checking a box in Visual Studio.
• About dotnet build, this is just something that's called underneath when running dotnet pack to author a Fable package. But consumer users don't need to run dotnet build at all. Not sure what would be the benefits of using dotnet build vs dotnet fable. Regarding dotnet watch, the watch mechanism in Fable has been far superior from the very beginning :) Fable actually doesn't use FCS directly, but a fork maintained by ncave with improvements for incremental compilation.

Not entirely related but another couple of notes as an addendum:

• Actually, what worries me the most in this area is we're still using Dotnet.ProjInfo to parse the .fsproj. It works well but I'm always afraid that one update of the dotnet SDK will break it, as Dotnet.ProjInfo is not maintained anymore. I've tried a couple of times to update to ionide/proj-info but I've never been successful (don't remember which errors I got). Any help here is appreciated.
• To have an idea of the complications regarding packages, I explored precompilation of packages last year (mentioned in this blog post). I spent several months tuning it and the feature is now included in Fable, but almost nobody uses it as the benefits are not very big and it brings other problems of its own: precompiling brings some overhead and you've to redo it every time a package or the Fable version changes, and it's difficult to get a cache location in CI.