coc-vscode-loader 1.0.3 → 1.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +2 -1
- package/assets/tui-preview.png +0 -0
- package/converter/README.md +134 -0
- package/converter/package-lock.json +693 -0
- package/converter/package.json +19 -0
- package/converter/pnpm-lock.yaml +419 -0
- package/lib/index.js +117 -40
- package/package.json +10 -4
package/README.md
CHANGED
|
@@ -50,11 +50,12 @@ npm install coc-vscode-loader
|
|
|
50
50
|
## Features
|
|
51
51
|
|
|
52
52
|
- **Real conversion pipeline** — git clone → converter → npm install → esbuild → register to coc
|
|
53
|
+
- **Auto-fetch registry** — remote registry fetched in background on startup, no manual refresh needed
|
|
53
54
|
- **Incremental cache** — source/ keeps git repo, updates via git pull only
|
|
54
55
|
- **Commit tracking** — records commit SHA after install, visible in detail view
|
|
55
56
|
- **Update check** — `C` key compares against remote HEAD, shows `↑` when outdated
|
|
56
57
|
- **Auto restart** — `:CocRestart` triggered automatically on close when changes detected
|
|
57
|
-
- **
|
|
58
|
+
- **Manual registry update** — `:CocCommand loader.updateRegistry` also available for re-fetch
|
|
58
59
|
- **Install logs** — real command output per step, expandable
|
|
59
60
|
|
|
60
61
|
## Architecture
|
package/assets/tui-preview.png
CHANGED
|
Binary file
|
|
@@ -0,0 +1,134 @@
|
|
|
1
|
+
# converter — vscode → coc converter prototype
|
|
2
|
+
|
|
3
|
+
CLI tool that automatically converts VS Code extensions to coc.nvim plugins.
|
|
4
|
+
|
|
5
|
+
## Usage
|
|
6
|
+
|
|
7
|
+
```bash
|
|
8
|
+
# Convert a VS Code extension directory
|
|
9
|
+
npx tsx src/cli.ts convert ./vscode-ext/ -o ./coc-ext/
|
|
10
|
+
|
|
11
|
+
# Build and install to coc
|
|
12
|
+
cd ./coc-ext && npm install && npm run build
|
|
13
|
+
cd ~/.config/coc/extensions && npm install /path/to/coc-ext
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
## Verified conversions
|
|
17
|
+
|
|
18
|
+
| Plugin | Type | Auto-detected | Build | Working | Notes |
|
|
19
|
+
|--------|------|---------------|-------|---------|-------|
|
|
20
|
+
| Volar (Vue) | TS bridge | `@vue/language-server` + `typescript` | ✅ | ✅ | Requires modified coc-tsserver |
|
|
21
|
+
| Prisma | Pure LSP | `@prisma/language-server` | ✅ | ✅ | Auto-detects bin entry |
|
|
22
|
+
| HTML CSS Support | Direct API | — | ✅ | ✅ | Handles API differences |
|
|
23
|
+
|
|
24
|
+
### Plugin types
|
|
25
|
+
|
|
26
|
+
| Type | Description | Approach | Example |
|
|
27
|
+
|------|-------------|----------|---------|
|
|
28
|
+
| **TS bridge** | Language plugins depending on TypeScript LSP | Generate `tsserver/request` bridge + `typescriptServerPlugins` | Volar |
|
|
29
|
+
| **Pure LSP** | Standard LSP using LanguageClient | Generate LanguageClient entry + server dependency injection | Prisma |
|
|
30
|
+
| **Direct API** | Direct coc.nvim API calls (no LanguageClient) | Keep original `extension.ts` as entry, no bridge | HTML CSS Support |
|
|
31
|
+
|
|
32
|
+
TS bridge plugins require a modified coc-tsserver ([PR #493](https://github.com/neoclide/coc-tsserver/pull/493)):
|
|
33
|
+
|
|
34
|
+
```bash
|
|
35
|
+
cd ~/.config/coc/extensions
|
|
36
|
+
npm install ChuYanLon/coc-tsserver --legacy-peer-deps
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
## Architecture
|
|
40
|
+
|
|
41
|
+
```
|
|
42
|
+
Input: VS Code extension directory
|
|
43
|
+
│
|
|
44
|
+
├─ scanner Analyze API → detect plugin type
|
|
45
|
+
├─ transforms/ AST transforms
|
|
46
|
+
│ ├─ import-mapping from 'vscode' → from 'coc.nvim'
|
|
47
|
+
│ ├─ class-to-factory new Xxx() → Xxx.create()
|
|
48
|
+
│ ├─ provider-register Adapt provider registration signatures
|
|
49
|
+
│ ├─ language-client Adapt LanguageClient signatures
|
|
50
|
+
│ └─ enum-offset Comment on enum value offsets
|
|
51
|
+
├─ mark-unsupported Replace/mark missing APIs (getWordRangeAtPosition, fileName, etc.)
|
|
52
|
+
├─ generate src/index.ts Main entry (bridge / LanguageClient / direct templates)
|
|
53
|
+
├─ generate package.json Dependencies / esbuild external config
|
|
54
|
+
└─ generate esbuild.mjs Build config
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
## Bridge preset system
|
|
58
|
+
|
|
59
|
+
Bridge logic is preset-driven rather than hardcoded:
|
|
60
|
+
|
|
61
|
+
```typescript
|
|
62
|
+
// presets.ts - all bridge presets defined here
|
|
63
|
+
const PRESETS = {
|
|
64
|
+
'ts-bridge': {
|
|
65
|
+
notification: 'tsserver/request',
|
|
66
|
+
responseNotification: 'tsserver/response',
|
|
67
|
+
handler: { type: 'command', command: 'typescript.tsserverRequest' },
|
|
68
|
+
extraDeps: ['typescript'],
|
|
69
|
+
},
|
|
70
|
+
// future: python-bridge, rust-bridge, etc.
|
|
71
|
+
}
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
`convert.ts` only calls `getActivePresets()` + `generateBridgeCode()`, it never touches bridge logic directly.
|
|
75
|
+
Adding a new bridge type = add a new preset in `presets.ts`, no changes to main flow.
|
|
76
|
+
|
|
77
|
+
See [coc-vscode-registry/docs/converter-design-v2.md](https://github.com/coc-plugin/coc-vscode-registry/blob/main/docs/converter-design-v2.md).
|
|
78
|
+
|
|
79
|
+
## File structure
|
|
80
|
+
|
|
81
|
+
| File | Lines | Description |
|
|
82
|
+
|------|-------|-------------|
|
|
83
|
+
| `src/cli.ts` | 28 | CLI entry |
|
|
84
|
+
| `src/convert.ts` | 484 | Main flow + template generation + API replacement |
|
|
85
|
+
| `src/scanner.ts` | 136 | API scanner + plugin classification |
|
|
86
|
+
| `src/transforms/import-mapping.ts` | 47 | Import replacement |
|
|
87
|
+
| `src/transforms/language-client.ts` | 48 | LanguageClient adaptation |
|
|
88
|
+
| `src/transforms/class-to-factory.ts` | 54 | new Xxx() → Xxx.create() |
|
|
89
|
+
| `src/transforms/provider-register.ts` | 55 | Provider registration signature fixes |
|
|
90
|
+
| `src/transforms/enum-offset.ts` | 49 | Enum value offset annotations |
|
|
91
|
+
| **Total** | **~870** | |
|
|
92
|
+
|
|
93
|
+
## Handled API differences
|
|
94
|
+
|
|
95
|
+
| API | VS Code | coc.nvim | Handling |
|
|
96
|
+
|-----|---------|----------|----------|
|
|
97
|
+
| import | `from 'vscode'` | `from 'coc.nvim'` | Direct replace |
|
|
98
|
+
| Position/Range/Location etc. | `new Xxx()` | `Xxx.create()` | AST replace |
|
|
99
|
+
| EventEmitter | `EventEmitter<T>` | `Emitter<T>` | Direct replace |
|
|
100
|
+
| registerCompletionItemProvider | `(sel, p, ...t)` | `(name, shortcut, sel, p, t?)` | Pad arguments |
|
|
101
|
+
| registerCodeActionsProvider | `registerCodeActionsProvider` | `registerCodeActionProvider` | Rename |
|
|
102
|
+
| registerReferenceProvider | `registerReferenceProvider` | `registerReferencesProvider` | Rename |
|
|
103
|
+
| CompletionItem.create | `new CompletionItem(label, kind)` | `CompletionItem.create(label)` + `item.kind = kind` | kind set separately |
|
|
104
|
+
| Trigger characters | `" "` (string) | `[" "]` (array) | Rest param → array |
|
|
105
|
+
| CompletionItemKind enum | `Value = 11`, `Enum = 12` | `Value = 12`, `Enum = 13` | Offset by 1, symbols auto-adapt |
|
|
106
|
+
| documentSelector | `[{ language: 'xxx' }]` | Same | Auto-infer from package.json |
|
|
107
|
+
| getWordRangeAtPosition | `document.getWordRangeAtPosition()` | Not available | Inline word boundary calculation |
|
|
108
|
+
| fileName | `document.fileName` | Not available | Replace with `document.uri` |
|
|
109
|
+
| createTextEditorDecorationType | `window.createTextEditorDecorationType()` | Not available | Mark TODO |
|
|
110
|
+
| createWebviewPanel | `window.createWebviewPanel()` | Not available | Mark TODO |
|
|
111
|
+
|
|
112
|
+
### Missing API strategy
|
|
113
|
+
|
|
114
|
+
When a VS Code API has no coc.nvim equivalent, the approach is:
|
|
115
|
+
|
|
116
|
+
1. Find the [VS Code source](https://github.com/microsoft/vscode) implementation
|
|
117
|
+
2. Evaluate complexity:
|
|
118
|
+
- **Simple** (e.g. `getWordRangeAtPosition`) → inline polyfill
|
|
119
|
+
- **Complex** (e.g. decoration, webview) → mark TODO with explanation
|
|
120
|
+
3. Polyfill using existing coc APIs where possible, avoid new dependencies
|
|
121
|
+
|
|
122
|
+
Known VS Code API source locations:
|
|
123
|
+
- `getWordRangeAtPosition` → `src/vs/editor/common/core/wordHelper.ts`
|
|
124
|
+
- `TextDocument.fileName` → coc uses `document.uri` instead (`DocumentUri = string`)
|
|
125
|
+
- Decoration system → `src/vs/editor/common/viewModel/viewDecorations.ts`
|
|
126
|
+
|
|
127
|
+
## Key design decisions
|
|
128
|
+
|
|
129
|
+
- **Zero hardcoding** — server package names auto-detected from source
|
|
130
|
+
- **Bin entry fallback** — auto-detect and prefer `package.json` bin entry
|
|
131
|
+
- **Auto esbuild external injection** — detected server packages marked as external
|
|
132
|
+
- **Auto TS bridge injection** — `typescriptServerPlugins` + `tsserver/request` forwarding
|
|
133
|
+
- **Plugin classification** — auto-detect TS bridge / pure LSP / direct API
|
|
134
|
+
- **Missing API handling** — polyfill where possible, mark TODO otherwise
|