chore: Bump the all-nuget group with 6 updates by dependabot[bot] · Pull Request #4976 · fable-compiler/Fable

dependabot · 2026-09-16T06:51:19Z

Updated fantomas from 7.0.6 to 8.0.0.

Release notes

Sourced from fantomas's releases.

8.0.0

8.0.0 _Satanized - 15/09/2026

Changed

Stable release.

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0

8.0.0-beta-003

Changed

Updated the packages the command line tool is built against: editorconfig to 0.18.0, Serilog to 4.4.0, Spectre.Console to 0.57.2 and System.IO.Abstractions to 22.2.0. Only one of these is visible in what Fantomas does: editorconfig 0.18.0 scopes its cache of the .editorconfig files it has read to the parser that reads them, where it used to share one statically. Fantomas keeps a single parser for the process, so a file is still read once and no more. Fantomas.Core asks for the same FSharp.Core it always did, so nothing referencing it has to move. #3468

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-beta-003

8.0.0-beta-002

Fixed

Unexpected symbol '<' in expression - Fantomas 8 regression. When the left-hand side of =, >, <, % or %% spans several lines, the operator takes a line of its own one level in, as 8.0.0-beta-001 introduced. That level was measured from the enclosing indent rather than from the column the left-hand side starts at. The two are the same at the start of a binding, and differ after something like && (, where the operator then landed on the column of the left-hand side and was offside: the parser read < as the start of a type application and rejected the output. The layout now asks where its fresh line would land and adds whole indent levels until that clears the left-hand side, the way a chain's dots have cleared its head since 8.0.0-alpha-024, so the operator and the right-hand side sit one level to the right of it and every column stays a multiple of the indent size. That shared step is indentPast in Context.fs, the helper #3446 asked for once a second caller turned up. #3463

Special thanks to @nojaf and @shayanhabibi!

https://www.nuget.org/packages/fantomas/8.0.0-beta-002

8.0.0-beta-001

Changed

=, >, <, % and %% cannot start a line at the column of their left-hand side: there the parser reads =, > and < as the = of a binding, and reads % and %% inside a quotation as a splice. Fantomas already kept them off that column, but did so with the layout that keeps the right-hand side beside the operator whenever it is short enough to fit, which needs the page width and a column count to predict and moves a 0 around when an unrelated part of the line changes length. It now follows the rule proposed in fsharp/fslang-design#836: the expression fits on one line, or it does not and the operator stays with the left-hand side while the right-hand side moves one level in, or the left-hand side itself spans several lines, in which case the operator and the right-hand side each take a line of their own. fsharp_multiline_bracket_style = stroustrup still overrides this for a right-hand side that opens a bracket, which keeps hugging the operator. This is the first beta of 8.0.0: the style guide for this is not settled yet, so give it a try and report back on the design issue if something reads worse than what it replaces. #3434

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-beta-001

8.0.0-alpha-026

Changed

fsharp_multiline_bracket_style = stroustrup now applies to object expressions, so { stays on the line that opens the binding and new T with moves below it. Up to now object expressions were printed by the aligned branch whatever the setting said, which left { new T with on one line and made stroustrup the only bracket style that did not reach every bracket it names. The Microsoft style guide writes the form out under "Formatting object expressions" and Fantomas now produces it character for character. This was left alone in the belief that the layout was an offside error waiting to happen; it is not, and the compiler accepts it in a binding, a list item, a function argument, a lambda body, a match clause and a nested let alike. An object expression under stroustrup now lands where a record already landed in each of those positions. aligned, which is the default since 8.0.0-alpha-002, and cramped are untouched. #2990
fsharp_multiline_bracket_style = stroustrup now survives a binding whose signature broke across lines, and a match clause under fsharp_experimental_keep_indent_in_branch. Both were printed by branches written before stroustrup existed and never given a stroustrup-aware counterpart, so the setting was quietly overruled in each: a let whose parameters wrapped left its = alone on a line and indented the bracket below it, and a match clause under keep-indent did the same below the arrow. They now read = { and | _ -> {, with the items one level in and the closing bracket back at the column the binding or the clause started from, which is what the same code already produced when the signature fitted on one line or the setting was off. This reaches every bracket the setting names, so records, update records, anonymous records, anonymous structs, lists and arrays move with the object expressions of the entry above rather than behind them. The closing bracket of a match clause stays two columns right of the bar, because on the bar's own column the | of the next clause no longer parses. #3450

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-026

8.0.0-alpha-025

Fixed

A ! line of a .fantomasignore takes a path back out again even when a line above it matched the folder holding that path, so sub/* followed by !sub/keep formats and checks the files under sub/keep. Since 8.0.0-alpha-016 a folder an ignore file names is never opened, which is what a folder pattern should mean and is not what it can mean here: closing sub decides that sub/keep is not there, and the line that would have taken it back out is never reached. The files were not reported as ignored, they were never found, so --check passed over a scope smaller than the ignore file describes and doctor, which asks about one file and answers correctly, disagreed with the run about that same file. An ignore file that negates anything now leaves every folder open and asks about the files inside one at a time, which is what every version up to 8.0.0-alpha-015 did. An ignore file with no ! line in it still closes the folders it names. #3447

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-025

8.0.0-alpha-024

Fixed

The dots of a chain that breaks are indented past the head of the chain, instead of landing on the head's own column or to the left of it. A dot on the head's column reads as a new item rather than as the chain continuing, and inside a parenthesis the parser refuses the output outright: let v = ((someObject.First(a).Second(b).Third(c))) at two-space indentation produced code Fantomas would not accept from itself, so the file was left unformatted with a bug report on the console. The dots now step one indent level at a time until they clear the head, which keeps every column a multiple of the indent size; a chain whose dots already cleared its head is untouched. This replaces a branch that anchored a parenthesised chain on its opening parenthesis, written when only a real dot chain reached it. Since 8.0.0-alpha-014 a dotted long identifier is a chain too, so it also fired for the likes of Seq.map, which never breaks, and moved a lambda written behind such a call three columns for no reason. #3445

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-024

8.0.0-alpha-023

Fixed

An operator that starts with a star keeps a space on either side of it inside the parentheses wherever its name is written, so val inline ( *. ): ... and abstract member ( *. ): ... survive formatting. Only let ( *. ) a b = ... was spaced before; a val in a signature file and an abstract member in either kind of file came out as (*.), which opens a block comment and swallows the rest of the file. Multiplication is unaffected, because (*) is a token the lexer knows. #3443

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-023

8.0.0-alpha-022

Added

Extension members on tuple types, type (int * int) with ... and type struct (int * int) with ..., format instead of failing. The parser accepts them since dotnet/fsharp#19602, and a type definition's name is now any type in the Oak tree rather than only an identifier. The tuple prints as written; no layout decision was added for it. #3436

Changed

Update FCS to 'Rotate [<return: X>] attributes during binding normalization', commit 74ec4f7df70717a162d6ffd23007603cf298fb8b #3436

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-022

8.0.0-alpha-021

Fixed

A call in the middle of a chain keeps its parenthesis against the member name when its lambda argument no longer fits, and breaks behind it instead. Up to now the whole argument moved down a line, ( and all, which is what the last call of a chain does, but for an earlier one it changes what the code means: a.Foo (x).Bar() passes (x).Bar() to Foo rather than calling Bar on the result. With a call behind it the compiler rejected the result with "This argument expression needs parentheses"; with a plain member behind it, such as .Value, nothing warned at all and the member quietly became part of the argument. Hanging the parameters under (fun would keep the parenthesis in place too, and the F# style guide rules that out, because the column they hang from is the length of the member name. The closing ) answers to fsharp_multi_line_lambda_closing_newline as it did before, and the last call of a chain is untouched, since nothing follows it to be swallowed. #3432

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-021

8.0.0-alpha-020

Fixed

A list or an array on the right of =, >, <, % or %% is indented from the binding again, so let a = b = [ ... ] breaks to b = [ with its items one level in and the ] back at the column of b. Since 8.0.0-alpha-003 both the items and the closing bracket sat a further level to the right. The right-hand side of these operators is indented so that a comment between the operator and that side lands below the operator, which is what #2944 asked for, and so that the lines under a chain or an application are not read as a continuation of the left-hand side. A list or an array needs neither: its bracket says where the right-hand side begins and indents its items from the left-hand side by itself, so indenting it again pushed the items and the closing bracket a level too far. This concerns aligned, which is the default, and stroustrup. cramped lines the items up under the opening bracket, so the indent never reached them and nothing changes there. Right-hand sides that open a bracket in some other way, such as seq { }, <@ @>, begin ... end and new T(...), still carry the extra level; where a no-break operator should put what follows it is a wider question than this fix. #3428

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-020

8.0.0-alpha-019

Fixed

A call on a constant receiver keeps its parenthesis tight, so "yow".Substring (0, 3) and 3L.ToString () come out as "yow".Substring(0, 3) and 3L.ToString(). 8.0.0-alpha-018 gave a constant receiver a space it was never meant to have. The rule there says a call keeps the space only when the whole thing being called is a plain dotted name, and the comment agreed at fslang-design#648 lists "yow".Substring(0, 3) under "a receiver that is not a name", beside (f x) and [ 1; 2 ]. The alpha carved constants back out on the reasoning that a constant is atomic rather than bracketed, which went past what was agreed and was not deliberate. A constant is a value, the rule asks for a name, so it goes tight. A type parameter really is a name, so 'T.set_StaticProperty (3) is unaffected. #3426

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-019

8.0.0-alpha-018

Added

doctor names the .fantomasignore above the one that governs a file, when a pattern in it would have skipped that file. Fantomas reads the nearest ignore file at or above a file and no other, so a pattern written at the root of a repository has no effect on a folder that has an ignore file of its own beside it. Up to now the report named the ignore file that did decide and said nothing about the one that did not, which answers "which file" and leaves "then why did mine not" for the reader to work out. It quotes the pattern that would have matched, with its line number, the way it already quotes the line that decided. --json carries every ignore file above the governing one under shadowed, each with wouldIgnore and the lines of it that match, whether or not it would have decided anything. #3423

Changed

The settings that ask for a space before the parenthesis of a call, fsharp_space_before_uppercase_invocation and fsharp_space_before_lowercase_invocation, now get a say only when the whole thing being called is a plain dotted name. Put a call, an index, a bracketed receiver, or a type application anywhere in it, and the parenthesis stays tight whatever the settings ask for. On default settings xs.map(fun a -> a + 1).filter (fun a -> a > 1) becomes xs.map(fun a -> a + 1).filter(fun a -> a > 1), which is the report this started from, and Foo().bar () and myList.[7].someFunction (arg) lose their space for the same reason. A plain dotted name is untouched however long it gets, so List.map (f) and Fantomas.FCS.Text.Range.unionRanges (r1, r2) keep the space they had, and so is a literal or type parameter receiver, since "yow".Substring (0, 3) and 'T.set_StaticProperty (3) are atomic rather than bracketed. Agreed at fslang-design#648 and written up under Formatting chain expressions. #3425
A type application now makes a call tight with no chain in sight, which is the part of the change above most likely to catch you out, because it reaches ordinary generic calls rather than fluent code. On default settings unbox<bool> (value), f<int> (x), List.map<int> (f) and jsOptions<Vis.Options> (fun o -> ...) all lose their space, since fsharp_space_before_lowercase_invocation is true and each of those is a lower-case name carrying type arguments. An upper-case generic call such as Dictionary<string, int>(x) was already tight by default and only moves if fsharp_space_before_uppercase_invocation is on. Fantomas does not add parentheses, so the far more common form without them, unbox<int> obj, is left exactly as written and never comes into it. #3425

Fixed

More expression forms count as open-ended, so a record, list, array or tuple that holds one of them in a non-last position stays multiline instead of collapsing onto a line that means something else. #3279 settled fun, if, match and try, and left the forms that wrap one of those or end in one: lazy, yield, return, do, assert and fixed, an assignment such as x.P <- fun y -> y, and let x = 1 in body. { A = 1; B = lazy fun x -> x; C = 3 } reads back as a lambda that swallowed C = 3. A wrapper around something that closes on its own, lazy a or x.P <- 1, collapses as it always did. When this happens, why, and how to get the single line back is written up under Open-ended expressions. #3424

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-018

8.0.0-alpha-017

Added

fantomas doctor <file> walks one file through everything Fantomas does to it and reports what happened at each step: whether the path is a file Fantomas formats, which .fantomasignore governs it and which line of that file decided, which settings apply and which .editorconfig set each one, what formatting produced and where the result first parts from the file, whether Fantomas accepts its own output, and whether formatting that output again leaves it alone. It writes nothing, so it is safe against a working tree you have not committed. Every question it answers was answerable before only by reading two configuration formats by hand and knowing the order Fantomas resolves them in. It takes one file rather than a folder, because the answers differ per file, and it exits 0 for a file it could diagnose whatever it found, 1 for a path it cannot look at or a step that failed. --json writes the same walk as one document with a key per step. #3421
The .fantomasignore line that matched a path is now knowable rather than only the yes or no. doctor quotes it with its line number, the way git check-ignore -v does, and names every line that matches when more than one does, since a ! pattern further down is exactly the case nobody spots by eye. #3421
doctor decides whether a file would be rewritten the way a format run decides it, by comparing the text as it is. A file whose line endings are the only thing out of step is therefore reported as needing formatting, where fantomas check deliberately overlooks that difference and calls the same file already formatted. What it reports is where the file and the result first part, rather than a count of the lines that differ by position: that is not a count of edits, because splitting one long line into five moves every line below it. #3421
A file under a folder a compiler or a package manager wrote, such as obj, is named as such by doctor. A run over the tree above it never opens that folder, whatever the ignore file says, and sending its owner to read their .fantomasignore sends them to read the wrong file. #3421

Changed

Breaking: output that Fantomas will not accept from itself is reported as what it is, and shows you the part of that output it would not accept. Fantomas produced code that is not valid F#. read as though the file were at fault, and reaching it always means the opposite: the input parsed, or a parse failure would have been reported instead. The report now says that nothing was written and the file is untouched, that this is a bug in Fantomas rather than a problem with the code, and where to report it, in the shape a parse failure and an unmodellable construct already print. #3419
Breaking: that report carries what the parser said about the rejected output, and the lines of the output around it with a caret under the failure, so there is a small reproduction to cut from it. Up to now the run said only that something was invalid, and finding out what meant running again with --force and reading the result. The diagnostics carry no line and column of their own: the output they would count into is written nowhere, so a position in it is a coordinate you cannot follow, and a path an editor could open would take you to the wrong line of the right file. The carets say where, and the report says out loud that the lines below it are the output rather than your file. --json carries the same diagnostics in the diagnostics array a parse failure already uses. fantomas check reports all of it the same way, where it used to run the whole explanation on after could not be checked:. #3419
The two reports that ask you to file a bug, for output Fantomas would not accept and for a construct it cannot model, name one place to send it rather than two. They used to add the issue tracker as an alternative for a file too large for the online tool to carry, which offered a choice at the point somebody least wants one. #3419
Breaking: Fantomas.Core.CodeFormatter.IsValidFSharpCodeAsync became ValidateFSharpCodeAsync and answers with a ValidationResult rather than a bool. Read .IsValid off it where the verdict was all you wanted; .Diagnostics is what Fantomas refused, positioned, and is empty exactly when the source is valid. The boolean discarded it, so anything that had to say why had to parse the source a second time to find out, which is why the tool could not show you its own bad output. A warning Fantomas tolerates, such as #3396 on IWSAM types, is not among them. #3419

Fixed

A [<return: ...>] attribute written in front of an extern declaration was dropped from the output. The parser moves such an attribute out of the binding's attribute list and into its arity information, and the extern path never looked there, so the line was silently deleted. Bindings already put those attributes back; extern now does the same. An attribute written on the return type itself, extern [<MarshalAs(UnmanagedType.I1)>] bool f(int options), is reported in both places and stays where it was written. #3420

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-017

8.0.0-alpha-016

Added

fantomas check <paths> and fantomas daemon, beside the --check and --daemon flags that named them. Both flags keep working and are not deprecated, so no pipeline and no editor integration has anything to change; each means exactly what its command means. The commands exist because a command can have a --help page of its own and a flag cannot: fantomas check --help lists the flags checking has any use for and leaves out the ones it would refuse. When standard error is a terminal, the older spelling prints a one line note saying how it is spelled now; a redirected stream never sees it, so it stays out of build logs and out of the daemon an editor starts. #3416
fantomas profile <paths>, replacing the --profile flag. It formats one file at a time so the timings can be compared, writes nothing, reports every file slowest first with its line count and the number of define combinations it had to format, and ends with a total. --profile measured files formatted in parallel, so each stopwatch recorded wall clock under contention: a six line signature file and a file of several thousand lines came back with the same figure. #3416
A --help page for each command. fantomas --help is the overview, with the commands, the flags, worked examples and links; fantomas check --help, fantomas profile --help and fantomas daemon --help are about one command each. Which flags a command's page lists is asked of the same rule that refuses them at run time, so the page cannot come to disagree with the tool. Every page names the tool the way this run was started, so a local tool install is shown dotnet fantomas rather than a command it does not have. #3416
--flag=value alongside --flag value, so --out=build and --verbosity=d work. Only the space separated form was accepted before, and --out=build was read as an input path that does not exist. #3416
-- ends the flags, so a path beginning with a dash can be named after it. It used to be read as an input path itself, which meant no such path could be given at all. #3416
--json for fantomas profile, carrying the same files as the text report with each file's line count, define combinations and milliseconds, and the run's own total as elapsedMilliseconds. Ordered by path rather than slowest first, since a reader that wants them by time can sort them. #3416
Running with no path at all formats the folder you are in, so fantomas is fantomas ., and check and profile read a bare invocation the same way. Formatting and checking used to refuse with No input path provided. This is what ruff format and dotnet format do. Note that it walks every F# file below the working directory, and that a .fantomasignore in a repository below it governs only that repository's files. #3416

Changed

Breaking: Fantomas.Core.ParseException now derives from FormatException, as the other exceptions the library raises already did, so :? FormatException catches every way formatting can fail. It could not before: it was declared with F#'s exception keyword, which cannot name a base class. Its Message names the first error by position instead of dumping every diagnostic record through %A, and the records are reachable as .Diagnostics rather than only by matching the exception pattern. Code matching | ParseException diagnostics -> becomes | :? ParseException as e -> e.Diagnostics; raising and constructing it are unchanged. #3415
A construct Fantomas cannot model is now reported through the same mechanism as a parse failure, instead of as a %A dump of a syntax tree node in the middle of the message. The report says in words what could not be modelled, names the union case responsible, positions it in the file being formatted rather than in the tmp.fsx the parser was handed, and draws a snippet of the source with a caret under the construct, so the enclosing declaration is visible without having to bisect the file by hand. The syntax tree node is still reported, at --verbosity d, where it serves whoever triages the issue rather than whoever files it. This covers every such report, from a type the transformer has no Oak node for to the chain and leading-keyword invariants behind it. --check and the daemon position them the same way, so an editor shows its user the snippet rather than a bare line and column. #3415
Breaking: everything a format or check run prints was rewritten. Each file gets a sentence of its own opening with a status character, + src/A.fs was formatted., and the run ends with a line of counts, 2 files formatted, 30 unchanged. This replaces the bordered table of headings that a folder run printed, which bypassed the logger and so carried no timestamp at --verbosity d while everything around it did. A run over a single named file is answered on its own terms and has no summary added to it. Any script reading this output needs updating; --json exists for a caller that has to act on the result rather than read it. #3416
Breaking: .fantomasignore is resolved per file, the nearest one at or above it, which is what the daemon has always done. The command line used to resolve one file for the whole run from the directory it started in, so an ignore file in a subfolder was honoured by an editor and invisible to a pipeline: the same file was skipped in one and formatted in the other. A nested ignore file that used to have no effect on a command line run now has one. #3416
Breaking: a folder that .fantomasignore names is no longer opened. Up to now every file inside it was found and then rejected one at a time; the folder is now passed over, so nothing inside it is read, counted or reported. A folder pattern spelled with a trailing separator, vendor/, closes the folder as vendor always did. Nothing is formatted that was not formatted before. #3416
Breaking: a run that skipped files no longer says how many. The count could not be honest: an ignore pattern naming a file can be counted, and one naming a folder cannot, because the folder is never opened and what is inside it is unknown by design. A number right about the first and blind to the second reads as though it covered both. A file named on the command line still gets a line of its own, since a count is the only other place a path could be accounted for and no count carries this one; a file found by walking a folder, and the folder itself, are named at --verbosity d. #3416
Breaking: --json no longer names a file that .fantomasignore matched, and ignored is no longer a status a file can carry. Nothing counts them in its place, for the reason above: files is what the run looked at. #3416
Breaking: a token beginning with a dash that is not a flag Fantomas has is reported as an unknown flag, with the nearest flag it could be a misspelling of. fantomas --chek src said Input path '--chek' not found. and now says '--chek' is not a Fantomas flag. Did you mean '--check'? Every unrecognised token used to be taken for an input path, so a misspelled flag was reported as a file that is not there. #3416
Breaking: a malformed command line exits 1 rather than 2. The documented exit codes have only ever been 0, 99 and 1; 2 came from the argument parser and was never one Fantomas chose. #3416
Breaking: repeating a flag is allowed and the last one wins, where it used to be refused outright with argument '--check' has been specified more than once. This is the Unix norm and stops a script that builds its arguments up from failing on a duplicate. --out is the exception and is still refused, because it decides where files are written and choosing between two of them quietly is choosing where the work lands. #3416
Breaking: a file that could not be parsed is reported as src/A.fs could not be parsed by Fantomas: rather than Fantomas could not parse src/A.fs:, and a construct that could not be modelled as src/A.fs could not be formatted by Fantomas:. Every line of a report now begins with the path it is about, so the column can be read down. A script matching on the old text needs updating. #3416
Breaking: --check no longer reports a file that will not parse twice, once as an error and once as needing formatting. It is an error and nothing else, which is also what its exit code has always said. #3416
Breaking: --force announces invalid output as a warning on standard error rather than on standard out, and says what happened: src/A.fs was formatted, but the result is not valid F# code. It was written because --force was given. It says Fantomas wrote F# it believes is not valid, which is the opposite of the ordinary run of things standard out carries. #3416
--version prints the commit hash trimmed to the short form the --help page has always shown, and the whole of it at --verbosity d. Fantomas.Client is unaffected: it cuts the version at + and drops the build metadata whatever it holds. #3416
A failure says what went wrong at any verbosity. The exception's message used to be kept for --verbosity d and nothing printed in its place at normal, so an unreadable file reported only A.fs could not be formatted. and left Access to the path is denied behind a flag nobody knew to pass. Detailed verbosity now adds the type and the stack trace below that line rather than instead of it. #3416
Colour is used where the terminal takes it and dropped where it does not, decided for standard out and standard error separately, so a run whose output is piped keeps its colour on the diagnostics still going to the terminal. The status character is +, =, -, ! and x where the output is redirected or the console is not UTF-8, and ✔, =, ○, ! and ✘ where it is; both carry the same five states, and the words beside them say the same thing either way. NO_COLOR is honoured. #3416
Files are reported in path order rather than in whichever order the file system returned them, so two machines running one command print the same thing. #3416
Breaking: a run writing to --out reports what was written rather than what changed, 32 files written to build, 2 reformatted., since under --out every input produces an output file whether or not its content changed. A single file named on the command line says where it went, src/A.fs was formatted and written to build/A.fs., where it used to say only that it was formatted or unchanged and leave the destination unmentioned. #3416
A run that looked at no file at all says so on standard error and exits 0, which a check used to pass over in silence: fantomas check on an empty folder, or on one an ignore file emptied, printed nothing and read as a green build. Formatting and checking now report this the same way, as they do everything else they both have to say. #3416

Fixed

Getting a 'no Oak node is defined for this type' error when formatting a p/invoke signature with nullability annotations. #3414
An extern declaration returning an array, such as extern byte[] f(int options), lost the element type of the array and was written as extern `[]` f(int options). #3415
A file whose formatted output is not valid F# named that file twice in one line, Failed to format file: A.fs : Formatting A.fs leads to invalid F# code, with a spaced colon in the middle. #3416
At --verbosity d, a single unchanged file was reported twice in two different spellings, once as 'A.fs' was unchanged and once as A.fs was unchanged. #3416

Removed

Breaking: the --profile flag. fantomas profile <paths> replaces it, and a run that names the flag is refused with '--profile' is not a Fantomas flag. 'profile' is a command: try 'fantomas profile <paths>'. and exits 1. It was not kept working as an alias, alone among the flags that became commands: the flag wrote formatted files to disk as a side effect of measuring them and the command deliberately writes nothing, so an alias would have gone on being accepted and silently stopped writing, which is worse than a run that stops and says what to type. --profile --check, which was accepted and did nothing at all, no longer has anything to combine. #3416

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-016

8.0.0-alpha-015

Added

Support for the record spread syntax introduced in F# preview, RFC FS-1151. A spread can appear in a record expression, { ...source; Field = value }, in an anonymous record expression, {| ...source; Field = value |}, and in the record representation of a type definition, type Target = { ...Source; Field: int }, in both implementation and signature files. #3400
Interpolated strings with a negative alignment, $"{value,-10}", now format instead of failing with a parse error. Alignment and format specifiers keep their existing layout, so $"{value,10:N2}" is unaffected. #3400
--json writes one JSON document to standard out describing what the run did, instead of the usual messages, for a script or an agent that has to act on the result rather than read it. Every file the run looked at is named with a status of formatted, unchanged, ignored, needs-formatting or error, and a file that failed to parse carries the severity, code, message and one based position of every diagnostic. Paths are reported as they were given, relative to the workingDirectory the document carries once. Standard out carries the document and nothing else, so it can be piped straight into a parser, while warnings still go to standard error. Exit codes are unchanged and the document repeats the one the process ends with. Works with --check, and is refused alongside --daemon, where standard out already carries the JSON-RPC protocol. #3412

Changed

Breaking: warnings and errors are written to standard error instead of standard out. Informational output stays on standard out, including --version and the files --check reports as needing formatting, so a caller can tell the tool's output apart from its diagnostics by stream. Scripts that capture standard out to detect failures need to capture standard error as well. #3399
Update FCS to 'Parser: recover on missing when conditions', commit d05075e098278aedcea3379159504d664628a495 #3400
Breaking: the --help page is written by Fantomas instead of by Argu. It carries the version, worked examples, what an input path may be, and links to the documentation, the F# Discord and the llms.txt files an LLM can read. Colours are used when the terminal supports them and dropped when standard out is redirected. -h is now accepted alongside --help. An argument error reports the complaint on standard error followed by a pointer to --help, where it used to print Argu's usage block. #3402
Breaking: a run over a single file reports the path it was given instead of only the file name, so fantomas src/A.fs prints src/A.fs was formatted. where it printed A.fs was formatted.. The same applies to the unchanged, ignored and failure messages. A run over several files already reported the path, so the two now agree. #3404
Breaking: a file that cannot be parsed is reported with the position of every diagnostic the parser produced, one MSBuild style line each, followed by a snippet of the source with two lines of context either side and a caret under the offending range. This replaces Could not parse the file. for a format run, the %A record dump and stack trace for a --check run, and the same %A dump the daemon used to hand editors. Diagnostics are ordered by position and columns are one based, matching what the F# compiler prints for the same file. #3405
Breaking: the messages for an input path Fantomas cannot work with are now the same whether the run formats or checks. --check used to report Input path 'x' is unsupported file type and Input path 'x' not found without a full stop where a format run ended both with one, and a run with no input path at all said No input path provided. when checking and Input path is missing. when formatting. Both now report Input path 'x' is an unsupported file type., Input path 'x' not found. and No input path provided. Call with --help for usage information. #3406
Breaking: a single file that .fantomasignore matches is reported the same way as an ignored file found while walking a folder. fantomas A.fs on an ignored file printed nothing unless --verbosity d was given, where fantomas ./folder containing only that file printed A.fs was ignored. Both now print it. A --check run reports the files it ignored at detailed verbosity whether they were named directly or found in a folder, where before only a directly named file was reported. #3406
At detailed verbosity, a run writing to --out now notes a file it found already formatted, as a run formatting in place always did. Both paths decide what formatting came to in the same place, so they say the same things about it. #3406
Breaking: --daemon no longer accepts the arguments that mean nothing to a daemon. --check, --out, --force, --profile, --json and input paths were all accepted and then silently ignored, so fantomas --daemon ./src looked like it would format a folder and did not. Any of them now reports which ones were refused and exits 1 without starting. --verbosity is still accepted, since it sets the level the daemon logs at, and --version wins outright. Fantomas.Client launches the daemon with no other arguments, so no editor integration is affected. #3412
--version now answers whatever else is on the command line, and before any of it is validated, so it can always be used to find out what you are running. It used to be refused alongside --daemon, and fantomas --version -v bogus exited 1 without printing a version. It is also written straight to standard out instead of through the logger, so it no longer picks up the timestamp and level prefix that --verbosity d adds, and reads the same at any verbosity. #3412
Breaking: Fantomas.Core is no longer binary compatible with v7. Several discriminated unions are structs now, which changes nothing about how they are written or matched, but an assembly compiled against v7 has to be rebuilt. #3407
A setting in .editorconfig that carries the fsharp_ prefix but is not a Fantomas setting now warns instead of being silently ignored, and where the intent is obvious the warning names the spelling that works. This catches a misspelling such as fsharp_multiline_brackets_style, and catches prefixing one of the four settings editorconfig itself defines, where fsharp_max_line_length never applied and max_line_length is the one that does. Settings without the fsharp_ prefix belong to other tools and are left alone. Every problem in one .editorconfig is reported together and only once per run, rather than once per formatted file, and --verbosity d writes out every setting the running version supports. #3401
.editorconfig keys and values are both matched without regard to case, as the editorconfig specification defines them. FSHARP_MAX_RECORD_WIDTH and fsharp_experimental_elmish = True used to be ignored. #3401
The daemon sends a fantomas/configurationWarning notification for every format request, naming the settings in the resolved configuration it could not act on, and sending an empty list when there are none so an editor can clear what it showed earlier. Additive to the JSON-RPC contract: a client that does not handle the method ignores it and keeps working. See the Fantomas.Client changelog for the client-side API. #3401

Fixed

--verbosity with an unrecognised value exited with code 1 and printed nothing, because the message was logged before the logger was configured. It now reports Invalid verbosity level on standard error. #3399
--out <folder> flattened the input tree: every file landed directly in the output folder, so two files with the same name in different subfolders silently overwrote each other. The output folder now mirrors the structure of the input folder, as the documentation already promised. #3403
--out <file> failed with Failed to format file and exit code 1 when the folder of the given path did not exist. Fantomas now creates it, along with the subfolders that mirroring an input folder needs. #3403
--out naming the input folder under a different spelling, such as fantomas src --out ./src, emptied every file it was given. The output file was opened, and therefore truncated, before the input was read. Nothing is written now until formatting has produced the text to write, which also leaves the previous output in place when formatting fails. #3403
--out pointing inside the input folder, such as fantomas src --out src/formatted, formatted the previous run's output again and nested it one folder deeper on every run. The output folder is left out of the input scan. #3403
fantomas src/ --out src formatted nothing and reported an empty table, where fantomas src --out src formatted the folder in place. A trailing separator made the two paths compare as different places, so every file below the input folder was taken for a previous run's output and skipped. The same applied to fantomas src --out src/. #3406
A file whose extension is not lowercase, such as A.FS, was refused as an unsupported file type, and one found while walking a folder was skipped. The extension is now compared without case, which is what a volume that ignores case, as macOS and Windows usually do, means by the same file. #3406
Given several input paths, a folder whose name contains a dot, such as fantomas my.stuff src, was taken for a file and reported as Failed to format file. A file with no extension was taken for a folder. Which one a path is, is now asked of the file system rather than guessed from the name. A single input path was already classified this way. #3406
A .fantomasignore pattern that cannot be matched against a path reported the raw exception, with its stack trace, through %A. It now names the file and the ignore file that could not be told apart, and keeps the exception for detailed verbosity. #3406
--profile reported Line count: 0 for a file whose line endings are not the ones the platform uses, because it counted occurrences of the platform's newline rather than line breaks. A file saved with line feeds counted nothing on Windows, and one saved with carriage returns counted nothing elsewhere. #3406
The daemon held its JSON-RPC message loop while reading an .editorconfig, so a request that arrived during it was not read until that finished. It hands the loop back first now, and serves one request at a time per file so that the configuration warnings for a file still arrive in the order the requests did. #3401
A value that meant something to one setting decided the outcome for every other setting, because each value was tried against every parser in turn. fsharp_max_record_width = cr failed the whole run with Carriage returns are not valid for F# code; it is now reported as a value that setting does not accept. A value is only read as the type its own setting has. #3401
A misspelling of one of the four settings editorconfig itself defines was silently ignored, where a misspelling of a fsharp_ setting was reported. max_line_lenght = 100 now says so. Only names within two edits of a setting Fantomas has are read this way, so settings belonging to other tools, indent_style among them, stay silent. #3401
A negative number was accepted for any setting that takes one, so fsharp_max_record_width = -5 formatted to nonsense widths without saying anything. It is now reported like any other value the setting does not accept. #3401

Special thanks to @claude and @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-015

8.0.0-alpha-014

Changed

Bump StreamJsonRpc to 2.25.29. This clears the NuGet vulnerability warnings coming from the transitive MessagePack and Nerdbank.MessagePack dependencies. #3393
Breaking: Expr.Chain is redesigned around a head, a list of ChainSegment and a ChainTerminal. Expr.DotLambda, Expr.DotIndexedGet, Expr.AppLongIdentAndSingleParenArg and Expr.NestedIndexWithoutDot are removed, and a dotted long identifier now yields Expr.Chain instead of Expr.OptVar in expression position. See the upgrade guide for how to migrate. #3385
Chains are laid out by a documented set of rules, written up in full under Chains. They are a proposal for the F# style guide and may still change. A chain that fits on one line is left alone. When one has to break, only a call claims a line of its own and plain property access rides along in front of it, where a comment between the steps previously put every step on its own line. A long run of property access now wraps into balanced lines instead of overflowing the margin. #3385
With fsharp_multi_line_lambda_closing_newline = false (the default), a match lambda argument keeps function beside the ( when the call is reached through a dot, matching what a call without a receiver already did. #3385
With fsharp_multi_line_lambda_closing_newline = true, a lambda argument whose opening line does not fit moves onto its own line instead of hanging its parameters under the opening parenthesis. This applies to calls with and without a receiver. #3385
Added InvariantViolationException, raised when Fantomas reaches a state its own model says is impossible. It derives from FormatException, carries the source range of the construct involved, and points at the issue tracker. #3385

Fixed

CLI refuses to format files containing IWSAM types (warning 3535 fails output validation). #3396
A space was added before the parenthesis of a call inside a _. shorthand lambda when fsharp_space_before_uppercase_invocation was enabled, producing code that does not compile. #3364

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-014

8.0.0-alpha-013

Changed

Improved formatting performance. Formatting is roughly 1.5 to 2 times faster and allocates around 65% less memory, depending on hardware. #3388
The command line tool now runs with Server GC, which speeds up formatting multiple files in parallel at the cost of a larger memory footprint. #3388

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-013

8.0.0-alpha-012

Changed

Bump FSharp.Core to 10.0.100. #3353

Fixed

Chained ? operator accesses (e.g. x?a("")?b(t)) no longer add a space before parenthesised arguments, which previously changed how the next ?member was parsed. Detected during AST→Oak transformation and represented as a new Expr.DynamicChain node so the printer can keep the chain tight; lone ? calls still respect SpaceBefore(Upper|Lower)caseInvocation. #3159

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-012

8.0.0-alpha-011

Fixed

Unicode strings with combining characters caused incorrect column tracking, leading to wrong indentation decisions. #2945

Special thanks to @Copilot and @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-011

8.0.0-alpha-010

Fixed

Struct constructor with unparenthesized parameter incorrectly renamed, causing a compile error. #3349

Special thanks to @Copilot and @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-010

8.0.0-alpha-009

Fixed

Comment without code after it in the current scope should retain their "parent" indentation. #2286
Code comment after expression is assigned to parenthesis. #1864
Misaligned comment in MultiLineBlockBracket. #1716
Comment unindented after DU cases. #2606
Comment on last match case has wrong indentation. #2653
Commented line inside of record should be indented at the same level as the fields #2482
Unindentation of comment before end of computation expression. #2476
Comments lost the indented after formatting. #2362
Comments can be lost or shifted when at the end of expressions. #932
Should not move the starting point of a single-line comment. #1233

Special thanks to @Copilot and @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-009

8.0.0-alpha-008

Added

Support for #elif preprocessor directive. #3268

Fixed

Multiline val body in signature files was not indented correctly. #3269
/// doc comment without associated declaration (e.g. at end of file) was duplicated when formatting. #2499
NamedIndexedPropertySet with two SynLongIdent removed space. #3273
%% (double-percent) infix operator moved to new line, producing invalid F#. #2107
Indentation warning when formatting match with long anonymous record discriminant. #1903
Index-without-dot with variable key followed by unit arguments added spurious spaces, e.g. dict[key] () () became dict [ key ] () (). #2519
Open-ended expressions (lambda, if-then-else, match, ...) in non-last positions of infix, tuple, list/array, and record expressions now stay multiline to preserve semantics. #3279
Lambda in tuple in list on single line changes code meaning. #3278
Custom operator applied to lambda collapses to single line changing semantics. #3274

Special thanks to @Copilot and @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-008

8.0.0-alpha-007

Changed

Update FCS to 'Treat warn directives as trivia', commit ab1f6ceaaec997d2854ac1c07a6c0f107675d95c #3263

Fixed

#nowarn in arbitrary places produces a parsing failure. #3263

Special thanks to @Copilot and @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-007

8.0.0-alpha-006

Fixed

Space between uppercase function name and uppercase parameter was dropped. #3264

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-006

8.0.0-alpha-005

Fixed

Closing > in nested multiline generic type applications violates offside rule. #3243
Index-without-dot syntax followed by application arguments was inconsistently formatted. #3259

Special thanks to @Copilot and @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-005

8.0.0-alpha-004

Changed

Improved error message when conditional compilation directives produce invalid syntax for some define combinations. #563

Fixed

Lambda in non-last record field is now parenthesized when record is collapsed to single line to avoid producing invalid code. #3246

Special thanks to @Copilot, @claude, @nojaf and @randrag!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-004

8.0.0-alpha-003

Fixed

End of line comments after infix operators are preserved correctly. #2287
Lambda closing parenthesis in chained method calls is no longer placed on its own line when MultiLineLambdaClosingNewline is enabled. #2553
Long & (AND) patterns now break across multiple lines to respect max line length. #1780
Empty array with trivia inside now has correct indentation in Stroustrup style. #3098
Multiline function type inside parentheses gets extra indentation to avoid compiler error. #3043
Trivia around paren lambda with conditional compilation no longer causes merge error. #2844
Type app closing angle bracket padded by previous expression length. #3179
Dynamic operator on result of qualified function call causes formatting error. #3135
Long delegate type with generic args no longer breaks around arrow. #2468
Idempotency problem when formatting NUnit Assert.That with lambda argument. #1740
Comment between lines of no-break infix expression no longer loses indentation. #2944
Hash directives around access modifier in module declaration no longer lose indentation. #3188

Special thanks to @, @Copilot, @dsyme and @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-003

8.0.0-alpha-002

Changed

Breaking: change default of MultilineBracketStyle from Cramped to Aligned. #3200

Special thanks to @nojaf!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-002

8.0.0-alpha-001

Changed

Update FCS to 'Remove LetOrUseKeyword from SynExprLetOrUseTrivia', commit 43932b4c7984d6562e91e5f1484868cd4f5befcf #3167

Special thanks to @Martin521, @Numpsy, @Thorium, @dawedawe, @karanveersp, @mattgallagher92, @nojaf and @tboby!

https://www.nuget.org/packages/fantomas/8.0.0-alpha-001

Commits viewable in compare view.

Updated fsharp-analyzers from 0.38.0 to 0.39.2.

Release notes

Sourced from fsharp-analyzers's releases.

0.39.2

Fixed

A repeated --script flag no longer silently drops all but the last occurrence. Every list-valued flag now accumulates the way --project and --analyzers-path already did, so --script a.fsx --script b.fsx means the same a...

Description has been truncated

Bumps fantomas from 7.0.6 to 8.0.0 Bumps fsharp-analyzers from 0.38.0 to 0.39.2 Bumps FSharp.Analyzers.SDK from 0.38.0 to 0.39.2 Bumps G-Research.FSharp.Analyzers from 0.24.0 to 0.25.0 Bumps Ionide.Analyzers from 0.18.0 to 0.19.0 Bumps Microsoft.NET.Test.Sdk from 18.9.0 to 18.10.1 --- updated-dependencies: - dependency-name: fantomas dependency-version: 8.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: all-nuget - dependency-name: fsharp-analyzers dependency-version: 0.39.2 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: all-nuget - dependency-name: FSharp.Analyzers.SDK dependency-version: 0.39.2 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: all-nuget - dependency-name: G-Research.FSharp.Analyzers dependency-version: 0.25.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: all-nuget - dependency-name: Ionide.Analyzers dependency-version: 0.19.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: all-nuget - dependency-name: Microsoft.NET.Test.Sdk dependency-version: 18.10.1 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: all-nuget - dependency-name: Microsoft.NET.Test.Sdk dependency-version: 18.10.1 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: all-nuget ... Signed-off-by: dependabot[bot] <support@github.com>

github-actions · 2026-09-16T06:58:06Z

Python Type Checking Results (Pyright)

Metric	Value
Total errors	34
Files with errors	4
Excluded files	4
New errors	✅ No

Excluded files with errors (4 files)

These files have known type errors and are excluded from CI. Remove from pyrightconfig.ci.json as errors are fixed.

File	Errors	Status
`temp/tests/Python/test_hash_set.py`	18	Excluded
`temp/tests/Python/test_applicative.py`	12	Excluded
`temp/tests/Python/test_nested_and_recursive_pattern.py`	2	Excluded
`temp/tests/Python/fable_modules/thoth_json_python/encode.py`	2	Excluded

dependabot Bot added the dependencies Pull requests that update a dependency file label Sep 16, 2026

dbrattli changed the title ~~Bump the all-nuget group with 6 updates~~ chore: Bump the all-nuget group with 6 updates Sep 16, 2026

Navigation Menu

Uh oh!

chore: Bump the all-nuget group with 6 updates - #4976

chore: Bump the all-nuget group with 6 updates#4976
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/dot-config/all-nuget-2b885e4efb

dependabot Bot commented on behalf of github Sep 16, 2026

Uh oh!

github-actions Bot commented Sep 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Uh oh!

Conversation

dependabot Bot commented on behalf of github Sep 16, 2026

8.0.0

8.0.0 Satanized - 15/09/2026

Changed

8.0.0-beta-003

8.0.0-beta-003

Changed

8.0.0-beta-002

8.0.0-beta-002

Fixed

8.0.0-beta-001

8.0.0-beta-001

Changed

8.0.0-alpha-026

8.0.0-alpha-026

Changed

8.0.0-alpha-025

8.0.0-alpha-025

Fixed

8.0.0-alpha-024

8.0.0-alpha-024

Fixed

8.0.0-alpha-023

8.0.0-alpha-023

Fixed

8.0.0-alpha-022

8.0.0-alpha-022

Added

Changed

8.0.0-alpha-021

8.0.0-alpha-021

Fixed

8.0.0-alpha-020

8.0.0-alpha-020

Fixed

8.0.0-alpha-019

8.0.0-alpha-019

Fixed

8.0.0-alpha-018

8.0.0-alpha-018

Added

Changed

Fixed

8.0.0-alpha-017

8.0.0-alpha-017

Added

Changed

Fixed

8.0.0-alpha-016

8.0.0-alpha-016

Added

Changed

Fixed

Removed

8.0.0-alpha-015

8.0.0-alpha-015

Added

Changed

Fixed

8.0.0-alpha-014

8.0.0-alpha-014

Changed

Fixed

8.0.0-alpha-013

8.0.0-alpha-013

Changed

8.0.0-alpha-012

8.0.0-alpha-012

Changed

Fixed

8.0.0-alpha-011

8.0.0-alpha-011

Fixed

8.0.0-alpha-010

8.0.0-alpha-010

Fixed

8.0.0-alpha-009

8.0.0-alpha-009

8.0.0 _Satanized - 15/09/2026