Repository navigation
Mixed open and module (alias) statements introduce newlines #3193
Description
Issue created from fantomas-online
Code
open System
open System.Threading
module IO = System.IO
open System.Regular
open System.Regular.TextResult
open System
open System.Threading
module IO = System.IO
open System.Regular
open System.Regular.Text
Problem description
There should be no newline
Extra information
- The formatted result breaks my code.
- The formatted result gives compiler warnings.
- I or my company would be willing to help fix this.
- I would like a release if this problem is solved.
Options
Fantomas main branch at 2025-09-08T06:57:30Z - 31029b1
Default Fantomas configuration
Did you know that you can ignore files when formatting by using a .fantomasignore file?
PS: It's unlikely that someone else will solve your specific issue, as it's something that you have a personal stake in.
Activity
nojaf commentedon Oct 29, 2025
This is only a problem from a certain point of view. What happens here makes sense to me according to Fantomas' internal rules. Open statements are grouped into an open list; module aliases are not part of that grouping. Thus we end up with three Oak nodes, two of which are multiline, which explains the newlines between the module aliases.
nojaf commentedon Feb 26, 2026
/repo-assist elaborate on a technical level why the result is what it is.
Ensure you keep it high level so the reporter can grasp it.
I'm not sure this is worth extending the Oak model for OpenList to also capture this.
github-actions commentedon Feb 26, 2026
🤖 This is an automated response from Repo Assist.
Here is a high-level technical explanation of why this happens.
What's going on under the hood
Fantomas formats code in two main phases:
Phase 1 — AST → Oak (intermediate representation)
After parsing,
ASTTransformer.fswalks the flat list of module-level declarations and uses an active pattern calledOpenLto greedily collect consecutiveopenstatements into a singleOpenListNode. The key word is consecutive: the pattern stops collecting the moment it encounters anything that is not anopen— including amodule alias(SynModuleDecl.ModuleAbbrev).So this input:
produces three separate Oak nodes:
OpenList [ open System; open System.Threading ]ModuleAbbrev (module IO = System.IO)OpenList [ open System.Regular; open System.Regular.Text ]Phase 2 — Printing with blank-line logic
When printing module-level declarations, Fantomas uses
colWithNlnWhenItemIsMultiline. This function adds a blank line between two adjacent declarations when either of them spans more than one source line (is "multiline").OpenListUse a more robust approach based on active patterns #1 is two lines → multilineModuleAbbrevis one lineOpenListVS support #3 is two lines → multilineBecause node #1 is multiline, a blank line is inserted before
module IO = .... Because node #3 is multiline, a blank line is inserted before it too. Both blank lines are a direct consequence of this general rule.Is it worth extending Oak's
OpenListNodeto also capture module aliases?As
@nojafnotes, it's not obvious that this is worth the complexity. TheOpenListNodeexists to group import declarations so they print without blank lines between them. Amodule aliasis semantically different (it's a type-level name binding, not an import). Merging them into a single node would blur that distinction in the Oak model and complicate the printer and transformer for what amounts to a rare mixed-style pattern.The blank lines Fantomas adds are not wrong — they follow the established rule that multiline blocks deserve visual breathing room. The formatting would look different from the source, but that's expected when Fantomas re-groups declarations. A fix would require either widening what
OpenLcaptures, or teaching the printer to suppress blank lines in a very specific case — both of which carry risk of subtle regressions elsewhere.deyanp commentedon Mar 2, 2026
@nojaf just a note from a team that has been using F# for building more than 150+ microservices in the past 6 years - open/module statements are the same, diff is only that you "rename" or alias a reference, so that it is easier to use it. However, both should participate in the same global ordering, because it is usually important which one is listed first, especially when the references contain the types with the same names, etc. So I can assure you, that for real life usage, this request is very justified ...
Do you mean you are rejecting this because it is too complicated to implement?
nojaf commentedon Mar 2, 2026
I closed this because it is kinda niche.
Real life usage of one company, only highlights a habit I'd say.
I can reopen but would like to see some more community interest.
deyanp commentedon Mar 13, 2026
@nojaf , the focus of my statement above was actually on
let me know if you disagree with that one
It should not matter if you open or rename a module, both should participate in the same global ondering, because as you know in F# the last open/module statement shadows the previous one, in case a type is in both ...
nojaf commentedon Mar 13, 2026
Thanks for the clarification.
From a maintainer perspective this is still a difficult change to justify. While I understand the reasoning behind grouping open statements and module aliases together, it is not clear whether this reflects a broader community practice or a convention used within a specific codebase.
Fantomas tends to be conservative when introducing stylistic exceptions because changes in formatting behaviour can easily trigger the opposite request from users who rely on the current output. In other words, changing this may resolve the issue for one group while causing others to report that Fantomas no longer respects the behaviour they expect.
It is also worth noting that Fantomas follows the style described in the documentation:
https://fsprojects.github.io/fantomas/docs/end-users/StyleGuide.html
In that model, open statements are treated as a group of imports, while other declarations such as module aliases are separate constructs. The current formatting behaviour reflects that distinction.
For now I would prefer to wait for broader community interest before introducing a special rule for this case.