Have we thought about bundling an external solution explorer?

[farlee2121]

The solution explorer seems like a good bit of code to maintain and a source of many feature requests.
It also seems like separable sub-problem.

Has bundling a 3rd party solution explorer been considered?
Are there constraints or benefits that make a first party explorer preferable?

• I noticed that project edits trickle down to FSAC. Not sure if that's critical.

Possible 3rd-party Explorer

vscode-solution-explorer is a dedicated solution explorer project that I use it for C#. It doesn't need much lift to support F# and it already handles significant feature lifts like

• package management
• adding project references
• drag and drop
• Handling all project item types (i.e. Compile, Content, None) including linked files
• handling both new and old project file formats (not sure if Ionide supports this)

I recently contributed a few tweaks to smooth the F# experience (showing ordered files, open project file on click). They haven't been deployed yet though.

I think the main lift would be move file up/down and add file above/below.

[farlee2121]

The creator of vscode-solution-explorer also just added move file up/down for files in F# projects.

[baronfel]

That's certainly an idea but there are a lot of open questions I have. The primary ones are:

• The explorer we have is a projection of data that we already have to acquire for other purposes (getting project information to power the compilation) - is the data from this external solution explorer consumable/sharable in the same way? Can that data be ingested into FSAC in some way?
• What should FSAC do about clients that don't have access to this VSCode-specific extension? Vim, Emacs, etc won't have this extension available and so FSAC would continue to need its own ability to unpack and understand projects, so I'm not sure that we'd even be able to remove the concept entirely from FSAC.
• extensibility - if we want to add items to project right click menus, is there a way to extend this external component easily?

[baronfel]

Yep! We already use the former (via the proj-info library) to do project evaluation, since there is a lot of hard-earned knowledge into how to do that right, and IIRC the latter isn't really architected to be a drop-in thing - it's very tied to VS APIs and may not be easily embeddable. There's also the 'sharing' part I mentioned above - ideally to foster C#<->F# interop there would be one project system that each language server could be a client of, and there's no project-system component in VSCode to share IIRC.

[TheAngryByrd]

@farlee2121 this is the library @baronfel is referring to which in turn uses Microsoft.Build.

[farlee2121]

Thanks!

If I understand right, the Ionide tree view gets it's information through FSAC which is leaning on proj-info, which in turn leans on Microsoft.Build.

[TheAngryByrd]

Yep! Here's super high level diagram on what depends on what: https://ionide.io/#toolchain

[farlee2121]

Thats a helpful diagram! I've been looking at some of the "up for grabs" issues and that should help me get oriented.

[farlee2121]

I created an extension pack that demonstrates what I originally envisioned. The pack is published if you want to try it out. The F# features for vscode-solution-explorer are also released.

The pack very simply installs both Ionide and vscode-solution-explorer and hides the Ionide tree view by default (FSharp.enableTreeView = false).
This way the 3rd-party explorer essentially replaces the default Ionide project explorer tree view.

If we ever wanted to officially offload the explorer tree view, we could achieve a similar result using extensionDependencies instead of an extension pack. As previously mentioned though, this tree view does not respect Directory.Build.props or targets. It is manipulates project xml directly.