coc-vscode-loader — Run ANY VS Code extension in coc.nvim, zero config, automagic conversion

[ChuYanLon]

Ever wished you could just :CocInstall any VS Code extension and have it work?

Now you can.

:CocInstall coc-vscode-loader
:CocCommand loader.open

Pick an extension from the TUI — Volar, Prisma, Deno, Tailwind CSS, Biome, whatever. Hit install. Done.

🤯 How it works

Behind the scenes, it automatically converts VS Code API calls to coc.nvim equivalents:

• Import rewriting (from 'vscode' → from 'coc.nvim')
• Class→factory transforms
• LanguageClient adaptation
• Binary server auto-download (Deno, Biome, Taplo...)
• pip dependency auto-install (Ansible...)
• All automated, zero manual conversion

🔥 mason.nvim-style TUI + Registry website

Search, filter, install, update, uninstall — all from a floating window. Or browse the full collection online.

🚀 Ready-to-use extensions

Huge and growing collection. Everything from language servers to formatters to linters.

Browse the full registry: https://coc-plugin.github.io/coc-vscode-registry/

:CocCommand loader.open                    # TUI
:CocCommand loader.install <name>          # direct install

⚡ Quick start

:CocInstall coc-vscode-loader
:CocCommand loader.open

That's it. Pick your extensions. Enjoy.

---

Open source at https://github.com/coc-plugin/coc-vscode-loader — contributions welcome!

[ChuYanLon]

v1.5.2 released! 🎉

121 extensions supported across 70+ languages:

LSP — Vue (Volar), Angular, Svelte, Astro, Prisma, Rust Analyzer, Deno, Biome, Pyright, PHP Intelephense, Clangd, Tailwind CSS, Stylelint, Ansible, Terraform, Docker, Bash, Lua, Go, ...

Snippets — React, Next.js, SolidJS, Vue, Angular, Svelte, JavaScript, TypeScript, Python, PHP, Go, Rust, C/C++, C#, Java, Dart/Flutter, Ruby, Rails, HTML, CSS, SCSS, Less, Markdown, ...

Formatters — Prettier, ...

Plus formatters, linters, and completions for HTML, CSS, SCSS, Less, JSON, YAML, TOML, GraphQL, Markdown, Dockerfile, gitignore, Makefile, and more.

New in this release:

• Help view redesign — Mason-style per-tab education, typewriter animated header
• Real-time search — Press / to filter packages with keyword hints
• Cancel install — kills running processes
• Update indicators — badge + auto-check on open
• Language filter — to filter by language
• Queue visualization — Queued section for batch operations
• Window auto-resize — Adapts to terminal size changes

Full changelog: https://github.com/coc-plugin/coc-vscode-loader/releases/tag/v1.5.2

[ChuYanLon]

@Freed-Wu Thanks for sharing — I have been following your work on coc-alex, coc-bitbake, coc-nix, coc-mlir, write-good, jq. You tried macro preprocessing, runtime checking, manual forking — every route, and you know exactly where each one breaks.

Here is something interesting: after reading your comment I looked up those plugins and added alex, bitbake, jq, and write-good to the registry in a few minutes. That is the whole point — adding a new extension is just configuring a single registry entry. The pipeline does the rest: clone → convert (AST transforms, 1-3s) → build → install. Zero upstream changes needed.

134 entries and counting. Every category: LSP, snippets, direct-api, formatters, linters, completions. The pipeline is solid — 6 transforms + 5 steps, 167 tests, 3-layer CI, automated upstream monitoring.

What excites me is where this goes next. The converter handles most patterns well, but there are always edge cases — and you have probably hit more of them than anyone. You maintain coc-alex, you tried to port bitbake, nix, mlir, write-good, jq — you know exactly what makes an extension hard to adapt. That perspective is exactly what this project needs to go from 134 to something much bigger.

Repo at https://github.com/coc-plugin/coc-vscode-loader. Take a look at the registry structure and the pipeline — would love to hear your thoughts.

[Freed-Wu]

I have a question: How do you plan to handle Webview support for different editors like VSCode and CoC.nvim in your extension?

I try to use coc-webview. The following example comes from my coc-graphviz

import {
    ExtensionContext,
    Uri,
//# #if HAVE_VSCODE
    Webview
} from "vscode";
//# #elif HAVE_COC_NVIM
//# } from "coc.nvim";
//# import { Webview } from "coc-webview";
//# import { resolve } from "path";
//# #endif

[ChuYanLon]

@Freed-Wu Good question.

Currently webview handling is still preliminary — only createWebviewPanel gets commented out by the mark-unsupported step, and everything else (registerWebviewPanelSerializer, registerWebviewViewProvider, asWebviewUri, webview.html, webview.postMessage, etc.) passes through unchanged, which means TypeScript compilation fails.

There is no dedicated webview transform yet, and here's why: coc.nvim runs in a TUI environment (Neovim/Vim) with no HTML rendering engine. Webview fundamentally depends on Electron/Chromium, so it does not map well to terminal editors.

I looked at coc-webview — it opens pages in an external browser, which is a reasonable approach, but the API coverage is limited and the project has been unmaintained since early 2023. For now, extensions that heavily depend on webview are excluded from the registry. For extensions where webview is supplementary (like vscode-ansible, where the core LSP works fine without it), the current approach is to let the webview code fail to compile — the essential functionality still works.

Going forward, possible directions:

1. Expand mark-unsupported to cover all webview API calls + strip type references from imports, making the code compile while sacrificing webview features entirely.
2. Adapter layer — a step generator that maps VS Code webview API to coc-webview's surface, handling API differences automatically.
3. Proper coc.nvim webview polyfill — a full API coverage solution, but this is a significant project on its own.

Currently leaning toward option 1 as the immediate pragmatic step. Let's see how demand evolves before investing in the heavier approaches.

[Freed-Wu]

Going forward, possible directions:
Expand mark-unsupported to cover all webview API calls + strip type references from imports, making the code compile while sacrificing webview features entirely.

Before a proper coc.nvim webview polyfill is available, make the code can be compiled is more important. a webview polyfill is the futher work.

I conclude our discussion to https://github.com/coc-plugin/ . Fix any incorrectness found by you 😄

[ChuYanLon]

Before a proper coc.nvim webview polyfill is available, make the code can be compiled is more important. a webview polyfill is the futher work.

Agreed. I have expanded mark-unsupported to cover the remaining webview APIs (registerWebviewPanelSerializer, registerWebviewViewProvider, asWebviewUri, etc.) and stripped type references from imports so the code at least compiles. A proper polyfill can come later.

The org README has also been updated — cleaner structure with core projects, ecosystem listing, quick start, and contribution guide. The icon has been moved into the .github repo directly to avoid broken links.

[ChuYanLon]

v1.5.7 released! 🎉

Vim 9.0+ support — TUI now works in Vim too! The entire TUI has been refactored behind an EditorAPI abstraction layer with NvimEditor/VimEditor backends. Auto-detects editor at runtime. Covers 83/86 TUI features with identical 19 keymaps across both editors.

excludeDeps field — SourceStep can now filter out unwanted dependencies from source extensions. Supports prefix matching (e.g. @wdio matches @wdio/cli, @wdio/local-runner). Use with keepDeps to replace vendored/broken deps with proper npm versions.

New in registry: Code Runner (direct-api, 12 patches)

Converter fixes: LanguageClient transform now correctly matches new expressions, balanced-parenthesis matching for Location.create/new CodeAction/registerDocumentFormatProvider, smarter .fileName and .uri.fsPath regex patterns, workspace.saveAll patch support, and more.

Full changelog: https://github.com/coc-plugin/coc-vscode-loader/releases/tag/v1.5.7

[ChuYanLon]

v1.6.2 released! 🎉

This release focuses on infrastructure — the Registry Update Checker CI that automatically monitors upstream extension repos for breaking changes:

• Daily automated detection — runs twice daily (04:00/16:00 UTC), checks all 130+ upstream repos, auto-creates PRs when converter output differs from baseline
• Smart error handling — rate-limit handling, merge conflict resolution via rebase, stale cache detection, orphaned entry detection, per-entry error isolation
• switch.sh improvements — plugin cleanup, auto-build on local switch, npm 11 fix, TypeScript dependency fix for coc-tsserver

Full changelog: https://github.com/coc-plugin/coc-vscode-loader/releases/tag/v1.6.2