Create an API layer for external process

[MrLuje]

## Warning, I branched from the NET 6 version, so #606 should be merged first (ignore the first 4 commits for the review)

WIP on #627, it covers the following points:

• Create the lib layer (Add FSharpLint.Client project)
• Expose a version method for the Client/Console flow
• I guess it should also be enough to publish FSharpLint.Client nuget

Add --daemon flag to FSharpLint.Console
All the "tool location detection" and "process handling" is copied from Fantomas project and adapted, basically:

• try to locate FSharpLint.Console as a Local DotnetTool from current file, then as a Global DotnetTool then in PATH
• keep a cache of already running daemon (per version)
• communicate between FSharpLint.Client and the FSharpLint.Console daemon through JsonRpc

I'll rebase everything once #606 is merged

[knocte]

Good work @MrLuje!

I'll rebase everything once #606 is merged

Thanks, I plan to re-review and/or merge that PR (or an equivalent) this week, bare with me.

[MrLuje]

Added an FSHARPLINT_SEARCH_PATH_OVERRIDE env var that will mostly be used for testing that can override search location (global tool & local tool) and a test to ensure FCS is not referenced by FSharpLint.Client

[knocte]

Hello @MrLuje sorry for the delay here. Today I merged the NET5->NET6 transition. Can you now rebase this PR?
Thanks!

[MrLuje]

@knocte done

[knocte]

@MrLuje the consistency-chaser in me is wanting to suggest that we create here a similar type to Folder, e.g. File which uses FileInfo underneath (instead of DirectoryInfo)

[MrLuje]

I'm all for consistency but IMHO there is less value for this one :

• VersionRequest is one of the API entrypoint (whereas Folder was only used internally) and it may be less intuitive to use
• File check is already covered by ErrFileNotFound, so we may want to change it if we go with the FileInfo way

[knocte]

I know it has less value, but I'm just allergic to the PrimitiveObsession anti-pattern (since I came to know the type FileInfo, seeing a string for file paths makes my eyes bleed haha). I can make the change myself, I'll push to your branch yeah?

[knocte]

FTR https://hackernoon.com/what-is-primitive-obsession-and-how-can-we-fix-it-wh2f33ki ;)

[MrLuje]

@knocte sure, go for it :)

[knocte]

@MrLuje sure, I'll do it this week. BTW can you rebase the PR? looks like there is some conflict

[MrLuje]

@knocte done

[knocte]

@MrLuje side-note, the conflict is actually caused because there is a change in the 1st commit of this PR that has some unnecessary whitespace noise hehe:

diff --git a/src/FSharpLint.Console/FSharpLint.Console.fsproj b/src/FSharpLint.Console/FSharpLint.Console.fsproj
index e70053133..f97b5e02b 100644
--- a/src/FSharpLint.Console/FSharpLint.Console.fsproj
+++ b/src/FSharpLint.Console/FSharpLint.Console.fsproj
@@ -1,9 +1,7 @@
-<Project Sdk="Microsoft.NET.Sdk">
-
+<Project Sdk="Microsoft.NET.Sdk">
   <PropertyGroup>
     <OutputType>Exe</OutputType>
     <TargetFrameworks>net6.0</TargetFrameworks>
-
     <Title>FSharpLint.Console</Title>
     <Description>Console application to run FSharpLint.</Description>
     <PackageTags>F#;fsharp;lint;FSharpLint;fslint;cli</PackageTags>
@@ -14,15 +12,15 @@
     <IsPackable>true</IsPackable>
     <RollForward>Major</RollForward>
   </PropertyGroup>
-
   <ItemGroup>
     <Compile Include="Output.fs" />
+    <Compile Include="Version.fs" />
+    <Compile Include="Daemon.fs" />
     <Compile Include="Program.fs" />
   </ItemGroup>
-
   <ItemGroup>
     <ProjectReference Include="..\FSharpLint.Core\FSharpLint.Core.fsproj" />
+    <ProjectReference Include="..\FSharpLint.Client\FSharpLint.Client.fsproj" />
   </ItemGroup>
-
   <Import Project="..\..\.paket\Paket.Restore.targets" />
-</Project>
+</Project>
\ No newline at end of file

[knocte]

@knocte done

Oh, interesting, CI failed on your fork (macOS job), but I can't see the log because I guess I don't have permissions. Can you share it?

[MrLuje]

@knocte done

Oh, interesting, CI failed on your fork (macOS job), but I can't see the log because I guess I don't have permissions. Can you share it?

Not a lot more information from my side (it timed out after 6h, maybe a runner issue ?)

No more issue after a retry

[knocte]

@MrLuje sure, I'll do it this week. BTW can you rebase the PR? looks like there is some conflict

Hey @MrLuje, sorry for our delayed action on this, I just pushed a commit that introduces a File type, similar to Folder.

Now, there are a couple of things to fix here:

1. Early on when you published this PR for the first time, I saw a potential improvement about some lines of code you wrote, but I realised that the "improvable code fragment" could actually be detected by FSharpLint itself, and in fact we had a rule in the works to detect this. This rule is now merged to master, so if you rebase this PR, you will see the offending code and CI will tell you what to change and how :)
2. After working on the File type explained above, I've spotted another piece of code that is a bit confusing because it seems to be conflating files with folders, I will go ahead now (after I post this comment) to the "Files changed" tab and point it out there with more context.

[knocte]

@MrLuje see the code here above? it is feeding a "filePath" to the Folder type. So is it a file or a folder? if it's a folder, it should be renamed from filePath to dirPath.

[MrLuje]

It's a folder (getting the folder of a file)

[knocte]

@MrLuje ok this is confusing, I thought the point of the from function was to convert a path(string) to a proper type. So, in my mind, Folder.from would map a (folderPath:string) to a (folder:Folder), and so that's why we included a File type equivalent to the Folder type that has a From method that works this way.

If we want to get the folder where a file lives, I think we should create an API that is more similar to the already existing BCL's System.IO API, to avoid confusions. So, in System.IO, the way to do this is convert the filePath:string to a FileInfo, and then accessing the .Directory property. So how about changing Folder's From method to receive a folderPath (not filePath; when given a filePath it should error saying that it is a file, not a folder). So if in this piece of code you want to get the folder where certain path lives, just create it via File.From and then let's create a Folder property in File type?

[MrLuje]

I fear that it might be weird from a discovery POV (signature is a Folder but no clue that you have to go through a File before)
What about if Folder.From can handle both a filePath and a folderPath ? or a FromFile / FromFolder ?

[knocte]

@MrLuje I like the FromFile/FromFolder idea, let's do it

[MrLuje]

Done
I missed it when changing to FileInfo but I don't need Path.GetFullPath anymore, FileInfo handles it properly

[MrLuje]

@MrLuje sure, I'll do it this week. BTW can you rebase the PR? looks like there is some conflict

Hey @MrLuje, sorry for our delayed action on this, I just pushed a commit that introduces a File type, similar to Folder.

Now, there are a couple of things to fix here:

1. Early on when you published this PR for the first time, I saw a potential improvement about some lines of code you wrote, but I realised that the "improvable code fragment" could actually be detected by FSharpLint itself, and in fact we had a rule in the works to detect this. This rule is now merged to master, so if you rebase this PR, you will see the offending code and CI will tell you what to change and how :)
2. After working on the File type explained above, I've spotted another piece of code that is a bit confusing because it seems to be conflating files with folders, I will go ahead now (after I post this comment) to the "Files changed" tab and point it out there with more context.

Got it, cool new rule :)

[MrLuje]

@knocte done