[WIP] Allow selecting fsproj files into workspace

[purkhusid]

WHAT

🤖 Generated by Copilot at be8ee10

This pull request adds support for single F# project files (.fsproj) as a possible workspace configuration. It updates various modules and types to handle this scenario in the workspace peek feature, the build task generation, and the solution explorer panel. It also adds support for directories as results of the workspace peek feature.

🤖 Generated by Copilot at be8ee10

Oh, we are the coders of the F# land And we work with the WorkspacePeekFound We handle the Fsproj and the directory And we heave on the count of three

🛠️🌲📁

WHY

When working in a monorepo with multiple independent projects it is not feasible to load all the projects in the repository. This change allows the user to select the projects that they are working on and only load them.

HOW

🤖 Generated by Copilot at be8ee10

• Add support for single F# project files as workspaces (link, link, link, link, link, link, link, link, link, link, link, link, link, link, link)
  • Modify the WorkspacePeekFound type to include a Fsproj case for project files (link)
  • Modify the mapFound and parse functions in LanguageService.fs to handle the Fsproj case and return an array of WorkspacePeekFound values (link, link)
  • Modify the getProjectsFromWorkspacePeek and isLoadingWorkspaceComplete functions in Project.fs to handle the Fsproj case and return a list or an array of project file paths (link, link)
  • Modify the ConfiguredWorkspace type to include a Fsproj case for project files (link)
  • Modify the private function in Project.fs to convert a string value into a ConfiguredWorkspace value if it ends with ".fsproj" (link)
  • Modify the private function in Project.fs to check the validity of a ConfiguredWorkspace value if it is a Fsproj case (link)
  • Modify the private function in Project.fs to return the path of a ConfiguredWorkspace value if it is a Fsproj case (link)
  • Modify the setFromPeek function in Project.fs to convert a WorkspacePeekFound value into a ConfiguredWorkspace value if it is a Fsproj case (link)
  • Modify the equalPeek function in Project.fs to compare a ConfiguredWorkspace value and a WorkspacePeekFound value if they are both Fsproj cases (link)
  • Modify the text function in Project.fs to create a quick pick item for the workspace selection panel if the workspace peek contains a Fsproj case (link)
  • Modify the private function in Project.fs to return the priority of a WorkspacePeekFound value for the workspace selection panel if it is a Fsproj case (link)
  • Add a case to the pattern matching expression in the buildTaskListForSolution function in MSBuild.fs to handle the Fsproj case and return an empty sequence of tasks (link)
  • Add a case to the pattern matching expression in the private function in SolutionExplorer.fs to handle the Fsproj case and create a tree node for the project file (link)
• Change the logic of selecting a workspace from a list of WorkspacePeekFound values to use the pickFSACWorkspace function instead of preferring the solution file (link)
  • Comment out the original logic and add a TODO comment to rewrite it to make it more configurable (link)
  • Modify the private function in Project.fs to set the context and the status bar for the current workspace depending on the type of the ConfiguredWorkspace value (link)
• Remove an empty line from the module Project in Project.fs (link)

[purkhusid]

@baronfel @TheAngryByrd This is still WIP but I wanted to check if this was a feature that would be accepted.

The defaults would have to be rethough a bit since Ionide always loads the available sln file instead of prompting the user.

I was also thinking about adding a new command for selecting multiple fsprojs, and then an configuration option that allows the user to set their default fsprojs.

[baronfel]

There's a lot of overlap here between an already-existing slnf (solution filter) feature of MSBuild, but I don't see anything inherently wrong with the "open project + direct dependencies" scenario. I think as soon as you get to wanting to open "these N projects and their dependencies" I would look strongly at that format.

[purkhusid]

I thought about going the slnf route but the downside of that is that you also need to maintain an actual solution file which contains all the projects. The main motivator for me is to make it as frictionless as possible to open a repo and loading only the projects that you need for the work you are about to be doing.

How I envisioned it is that a developer would do the following:

1. Open the repo folder in VS Code
2. If they are about to do work on F#(Could be a polyglot monorepo) they would CTRL + P -> F#: Load Projects
   • Would pop up a multiselect list that contains all the F# projects in the repo
3. They would select the projects they are interested in
4. Ionide would load the projects
5. Start coding

This workflow is really nice because you can configure your workspace without having to mess with any files at. If you think we could make the slnf route as nice as the workflow I envisioned above then I would love to hear your ideas.

[purkhusid]

There is also one other way to make the dev experience even easier and that would be:

1. Dev opens repo folder in VS Code
2. If they are about to do work on F# they just open the F# file they are going to work on
3. Ionide would find out what fsproj the opened file belongs to and would load it

This would be my ideal workflow but I think it's also quite a bit more complex to implement and that's why I went the route that is in the PR. If you think that lazy loading the projects like this would be possible then I think I'll have a go at it if you could point me in the right direction.

[purkhusid]

I looked a bit into the lazy loading of projects and it seems like the main blocker for doing it is that we can't tell what fsproj an .fs file belongs to without calling workspaceLoad for the project. Do you have any suggestions on a way to map fsproj -> .fs files without doing a full load of the workspace?

[baronfel]

No, there's no good way. In addition, our current mechanism is incomplete because the file could belong to multiple projects.

[baronfel]

In case you haven't seen it, slngen is some prior art in this space.