Better "Tests" detection about fsharp.formatting HOT 10 CLOSED

How would one achieve this easily?

I think we just delete lines 426-433. projectFiles is used to generate projectInfos, and projectInfos is already filtering out test files using this property

We'd need to test but scanning the code, just delete 426-433.

from fsharp.formatting.

Hi there, thanks for bringing this up.
What would you suggest here? Something more along the lines of EndsWith?

from fsharp.formatting.

Another option is don't filter out test projects if they're specified by the --projects option. That would allow fsdocs build --projects "fsdocstester/src/Project1.fsproj"

I believe we'd get that functionality if we moved the "test" project filtering so that it only applies inside match case on line 392.

from fsharp.formatting.

Good suggestion!

from fsharp.formatting.

Hi there, thanks for bringing this up. What would you suggest here? Something more along the lines of EndsWith?

I'm guessing this code is trying to avoid cracking as we could look post crack at either IsTestProject or if Microsoft.NET.Test.Sdk is referenced.

from fsharp.formatting.

Honestly, just lean into cracking :) If you use something like buildalyzer to 'drive' the build out of proc it should be relatively stable across MSBuild versions, and this property only relies on evaluation not execution so changes in target ordering across SDK versions shouldn't impact you.

From a performance perspective, you can toggle MSBuild Server on (or wait for it to be toggled on by default) and a lot of the process-spawning overhead should just disappear.

from fsharp.formatting.

This code might actually pre-date Microsoft.NET.Test.Sdk 😅.
So if there is a better way to detect this I'm all ears.

from fsharp.formatting.

<IsTestProject>true</IsTestProject> is the canonical way to detect this. IMO we should use it. The Microsoft.NET.Test.Sdk contributes setting this property by default, but it's also possible for projects to add it manually.

from fsharp.formatting.

That sounds good to me. How would one achieve this easily? Loading the fsproj file, running some target and reading the property? Something along those lines?

from fsharp.formatting.

You shouldn't need to run any targets - the act of loading the project file is evaluation, and after evaluation you have access to all properties that are statically-known (including those delivered by SDKs). Evaluation is generally quite fast, it's running design-time-builds (like editors need to to get compiler options) that takes some time.

from fsharp.formatting.