Skip to content

Conversation

@MrLuje
Copy link

@MrLuje MrLuje commented Dec 31, 2023

Branched from #637, so it should be merged first

See MrLuje/FSharpLint@9635b9a...MrLuje:FSharpLint:lint_layer diff for relevant changes

WIP on #627:

For reminder, the purpose of the API layer is to abstract away all FCS types so the caller can have a different FCS version than FSharpLint.

I duplicated types from https://github.com/fsprojects/FSharpLint/blob/master/src/FSharpLint.Core/Framework/Suggestion.fs to FSharpLint.Client and prefixed them with Client (eg: SuggestedFix => ClientSuggestedFix) to tell them apart. (I created ClientRange from scratch to avoid the FCS dependency) but that's open to discussion.

type LintFileRequest =
    {
        FilePath: string
        LintConfigPath: string option
    }

For now, the LintFileRequest takes the path to the file to lint and an optional LintConfigPath to a fsharplint.json file but I'm wondering about other scenario :

  • If no config is specified, defaultConfiguration will be used (same with an invalid LintConfigPath)
  • If a valid fsharplint.json is specified through LintConfigPath, it will be used
  • What about if LintConfigPath isn't specified but there is an existing fsharplint.json in the project ? is there a standard location for fsharplint.json or an existing detection method ? (next to solution file, parse [fc]sproj, etc)

ensure we can reuse an already found daemon version from another folder
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant