discussion: multi target F# libraries (IL, WebSharper, Fable, etc.)

[smoothdeveloper]

I'm wondering if there is any provision, that would enable to flag code for which documentation is generated, as "supported on target X,Y,Z"?

With the growing of F# into other ecosystems than dotnet, I wanted to suggest few points:

• considering extension points, so we could refer to types in other ecosystems documentation, in same way CLR types surface in the documentation https://fsprojects.github.io/FSharp.Formatting/reference/fsharp-formatting-codeformat-errorkind.html#Error
• having a filtered view where end user would select the targets of interest while browsing the documentation (if I'm interested in CLR & Fable to rust or Fable to python only, while browsing a given library)
• engaging with other communities that manage similar projects in the target ecosystems, to obtain guidance on how to tackle this the best from their perspective, leveraging their knowledge of how similar tools work there

I came across this: https://devdocs.io/, it would be great for fsdocs enabled projects to surface there.

[github-actions]

🤖 This is an automated response from Repo Assist.

Great discussion! This relates to the recently opened issue #1064 ("Consider different docs for different TFMs"), which focuses specifically on the multi-TFM/multi-target API documentation problem.

Here's how the two topics connect and some thoughts on feasibility:

What's currently possible

The (*** condition: fsx ***) / (*** condition: prepare ***) system in literate scripts lets you write target-conditional code examples today. For selecting between Fable vs. CLR API documentation, there's no built-in mechanism yet.

The core challenge

fsdocs generates API docs from compiled assemblies (DLLs) via FSharp Compiler Services. A multi-target project produces multiple outputs (e.g. net8.0/MyLib.dll, netstandard2.0/MyLib.dll). At the moment, fsdocs picks one TFM and generates a single set of docs — it doesn't merge or diff the outputs.

For the Fable/WebSharper/F#-to-JS case specifically, those compilers typically don't produce a standard .NET assembly at all, so FCS-based API introspection wouldn't apply directly. An extension point would need a different discovery mechanism.

Feasible near-term steps

1. TFM picker (like MSDN's .NET 8 / .NET Framework dropdown): generate separate API doc sets per TFM and add a switcher UI. See Consider different docs for different TFMs #1064 for a more detailed breakdown.
2. Conditional doc markup: allow XML doc comments to annotate availability, e.g. /// (platform name="Fable"/), which fsdocs would render as an availability badge — requiring no assembly-level change.
3. devdocs.io integration: fsdocs already generates structured HTML; the main work would be producing the entries.json / index.json manifest that devdocs.io expects. This would be a useful standalone contribution independent of the multi-target discussion.

The "filtered view" idea you describe is essentially what the TFM picker in #1064 would provide at the .NET level. Extending it to Fable/WebSharper targets would require either a custom plugin mechanism or separate doc-generation tooling (since those ecosystems don't produce standard .NET symbols).

Happy to expand on any of these approaches if it would help move things forward!

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@10f087607af87e4e89439161f1e5d4724235f396