Ionide-VSCode: F# language features built on FSAutoComplete and proj-info

Two upstream projects do the real work

Ionide-VSCode is described as a VS Code plugin that turns VS Code into a fully-fledged IDE for F# development, and the interesting part of the architecture is that the hard work is not in this repository.

The language features come from FSAutoComplete, the language server that powers them. The project and script loading come from proj-info, which handles working out what a project is made of. The plugin is the layer that connects those two to the editor and turns their answers into VS Code's own interfaces: completion, hovers, diagnostics, code actions, symbols.

That division has consequences. When a completion is wrong or a project fails to load, the question of where the bug is has a fairly short answer: it is in FSAutoComplete, in proj-info, or in the glue. The plugin is written in F#, which is also why its package manifest carries an unusual script, a call to ts2fable that generates Fable bindings from the TypeScript type definitions of semver into a source file under src/Imports. The manifest also depends on htmlparser2 and semver at runtime, with a development toolchain built on webpack, mocha, axios, showdown and toml.

The F# code is compiled into the extension, and the extension targets a Node runtime, with the manifest requiring Node 16.0.0 or later and pinning yarn 1.22.22 as the package manager. The repository also has paket.dependencies and paket.lock, a solution file, a Nuget.Config and a .tool-versions file, so the build mixes several .NET and JavaScript toolchains.

The feature list is mostly navigation

The features the project lists are worth reading as a list of what an F# developer expects from an IDE and does not get from a plain editor.

The navigation group is the largest. Go to Definition, Peek Definition, Find all references, highlighting of usages, Rename, show symbols in file, find symbol in workspace, and Go to MSDN help. There is also a generator for an open NAMESPACE line for a symbol, a match case generator, a way to go to a #load reference, and a command to generate a comment for the symbol.

The completion group includes syntax highlighting, auto completions, error highlighting with an error list and quick fixes based on errors, tooltips, method parameter hints, and the signature shown in the status bar and as a CodeLens or LineLens above the definition.

What is distinctive about the list is the set of integrations, and they are the reason to pick this plugin rather than a generic language server client. There is integration with F# Interactive, with Forge for project scaffolding and modification, with FSharpLint for extra hints and quick fixes, and with MSBuild for build, rebuild and clean. There is a solution and project explorer.

The MSBuild integration deserves a note, because build, rebuild and clean are the operations that a project needs on a day when something does not compile, and having them in the editor rather than in a terminal is a real difference in day-to-day work.

Debugging is a separate dependency, not a built-in

The requirements section is where the honest limits of the plugin appear, and they are worth reading before an install rather than after.

Two things are required. The .NET 8.0 or 9.0 SDK has to be present, and the VS Code C# plugin has to be installed. The second requirement is not a formality: the README states that Ionide's debugging capabilities rely on either the Omnisharp debugger or netcoredbg. In other words, the F# plugin borrows the .NET debugging infrastructure that ships with the C# extension, which means the C# extension has to be present, configured and working before debugging in F# works at all.

That coupling has a cost. An F# developer who only wants the C# extension absent now has to install it to get debugging, and a team with a locked-down extension policy has to allow it. It also means that when debugging misbehaves, the first thing to check is the C# extension and its debugger rather than the F# plugin.

The F# language features themselves have no such dependency beyond the SDK, and they are the part of the plugin that has the deepest integration with the language, from the #load navigation to the F# Interactive integration and the FSharpLint pass for extra hints and quick fixes.

There is also a distribution detail: the project is published on the VS Code Marketplace, and a pre-packaged version is available on the open-vsx.org registry, which the README mentions is bundled with the FOSS debugger from Samsung. Anyone working in an environment that restricts the Marketplace can use the open-vsx build instead, though the debugger bundled with it is a different arrangement from installing the C# extension yourself.

The build is a mix of two toolchains

Building the extension means building both an F# project and a JavaScript bundle, which explains the top-level layout.

The .NET side has an ionide-fsharp-vscode.sln solution, a global.json, a Nuget.Config, a lib directory, a build directory and a release directory, with paket handling the .NET dependencies through paket.dependencies and paket.lock. There is a .paket directory, a .config directory and a .tool-versions file that pins the tool versions for anyone using a version manager.

The JavaScript side is handled by webpack, with a webpack.config.js at the root, and the manifest declares the build tools. The single npm script in the manifest is the one that generates the Fable bindings:

  "scripts": {
    "gen:semver": "ts2fable node_modules/@types/semver/{classes,functions,internals,ranges}/*.d.ts  node_modules/@types/semver/index.d.ts src/Imports/Semver.fs"
  },

So semver's TypeScript definitions are converted into F# code that the extension compiles directly. That is a small but telling detail: the type information for the semver library is consumed as F#, not reimplemented, which keeps the binding honest at the cost of a code generation step in the build.

The manifest also lists htmlparser2 and semver as runtime dependencies and a development toolchain including mocha for tests, showdown for markdown conversion, xmldom and xpath for XML handling, ws and xhr2 for network access, and vscode-languageclient and vscode-debugadapter for the editor protocols. There are build.sh and build.cmd scripts at the root for Unix and Windows, plus a .gitpod.yml and a .gitpod directory, so a Gitpod-based development environment is provided as well as local setup instructions in CONTRIBUTING.md.

Releases are manual, and the version numbers have moved

The releasing section is short, and the fact that it is short tells you the project is not on continuous deployment.

The process is three steps. Update RELEASE_NOTES.md with the new version number, the date in DD.MM.YYYY format, and brief release notes. Push the change to the main branch. A maintainer can then run the release workflow from GitHub's actions page.

That last step is the one to notice. A maintainer triggers the release, which means a new version appears on the Marketplace only when someone deliberately publishes it. The published version and the state of the main branch can therefore differ for as long as it takes somebody to run the workflow.

The version history shows the scale of movement. The recent releases are 7.31.1 on 2026-02-05, 7.30.0 on 2025-12-07 and 7.29.0 on 2025-11-13, and the last push to the repository was on 2026-10-10. The numbers are on a seven series with three-part version numbers, which is a lot of releases for a plugin, and the gap between the newest published release and the last commit is the practical thing to keep in mind when deciding whether to update.

The project is part of the wider Ionide plugin suite, is hosted under the ionide organisation, and carries Open Collective badges for backers and sponsors, so the funding model is visible in the README rather than hidden. Detailed documentation lives at ionide.io rather than in this repository, and the CONTRIBUTING.md file holds the process for getting a patch merged, with the README making an explicit point of the fact that expectations and process are written down to make contributing easier.

Editorial conclusion

Ionide-VSCode suits an F# developer who wants language features, project awareness and a solution explorer inside VS Code rather than a separate IDE. It is the wrong tool for anyone who needs debugging to work out of the box, since the debugging path depends on the OmniSharp or netcoredbg debugger and therefore on the C# extension being installed and configured, and the wrong tool for a team that wants an editor with no .NET SDK on the machine at all. Before you adopt it, install the .NET 8.0 or 9.0 SDK and the VS Code C# plugin, check that your solution and script loading behaves the way you expect, and read RELEASE_NOTES.md before upgrading, because the release line moves in minor versions that can change what the plugin expects from the SDK.

Frequently asked questions

Official sources

1. ionide/ionide-vscode-fsharp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases