Update Fantomas.Client to 0.12.0-beta-002 - #1543
Merged
Merged
Conversation
nojaf
force-pushed
the
upgrade-fantomas-client
branch
from
August 28, 2026 21:23
22ef804 to
4879da4
Compare
0.12.0 exposes two things FSAC previously had no way to see: a log delegate saying which Fantomas a folder resolved to and where it was found, and an event naming the settings in the resolved configuration that Fantomas could not act on. Both were silent failures before. A tool found on the PATH formats exactly as successfully as the version a repository pins, and an unknown fsharp_ setting quietly applies a default, so neither was distinguishable from working. The log delegate goes to the existing Fantomas logger. Configuration warnings are reported once per file, deduplicated because the daemon raises the event on every format request rather than only when something changed. They name the version that could not act on the setting, an older Fantomas being a likelier cause than a typo, and offer to open the .editorconfig files that contributed along with the file being formatted, which needed window/showDocument wiring up on FSharpLspClient. Two fixes to the surrounding code: - The service owning the daemons was never disposed, so every `fantomas daemon` process FSAC started outlived the session that started it. - Fantomas response codes are read as FantomasResponseCode rather than bare ints. Only five were handled by name and the rest fell into one branch that printed the response record, so the message DaemonCreationFailed carries, which includes the standard error of the daemon that would not start, never reached a user, and a cancelled request was reported as a formatting failure. Paket.Restore.targets is regenerated by the paket 10.3.1 pinned in .config/dotnet-tools.json. It was left behind when that tool was bumped, and any build recreates it.
The previous run failed on infrastructure only: paket restore killed with 137 on both macOS runners, dotnet --info killed with 143 on ubuntu, and the Windows test host crashed on a FileSystemWatcher finalizer NullReferenceException that no code in this branch touches. Claude-Session: https://claude.ai/code/session_01BchWfZ7b2KCx5h4YCmcPnw
TheAngryByrd
force-pushed
the
upgrade-fantomas-client
branch
from
August 29, 2026 04:43
d283a99 to
e604119
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Dear @baronfel and @TheAngryByrd, I hope this PR finds you well.
I love you guys, just wanted to mention that!
The tl;dr here is that Fantomas can now report any settings in
.editorconfigthat are old an no longer used by the current version that is formatting the code.I did some testing on Mac and Linux, and I am quite confident in these changes.
I would merge this, and if all goes well, we eventually promote the beta label to stable.
0.12.0 exposes two things FSAC previously had no way to see: a log delegate saying which Fantomas a folder resolved to and where it was found, and an event naming the settings in the resolved configuration that Fantomas could not act on. Both were silent failures before. A tool found on the PATH formats exactly as successfully as the version a repository pins, and an unknown fsharp_ setting quietly applies a default, so neither was distinguishable from working.
The log delegate goes to the existing Fantomas logger. Configuration warnings are reported once per file, deduplicated because the daemon raises the event on every format request rather than only when something changed. They name the version that could not act on the setting, an older Fantomas being a likelier cause than a typo, and offer to open the .editorconfig files that contributed along with the file being formatted, which needed window/showDocument wiring up on FSharpLspClient.
Two fixes to the surrounding code:
The service owning the daemons was never disposed, so every
fantomas daemonprocess FSAC started outlived the session that started it.Fantomas response codes are read as FantomasResponseCode rather than bare ints. Only five were handled by name and the rest fell into one branch that printed the response record, so the message DaemonCreationFailed carries, which includes the standard error of the daemon that would not start, never reached a user, and a cancelled request was reported as a formatting failure.
Paket.Restore.targets is regenerated by the paket 10.3.1 pinned in .config/dotnet-tools.json. It was left behind when that tool was bumped, and any build recreates it.