拡張機能とエコシステムのサポート
Visual Studio Live Share の主な目標の 1 つは、開発者が "お気に入り" や高度にカスタマイズされたツールを使い快適に共同作業できるようにすることです。 このように、何を支援しているかにかかわらず、視覚的にはわかりやすく、人間工学的でありながら、アドホックなやり取りが頻繁に発生する可能性があります。 これを実現するには、コラボレーション セッション内の参加者が、個人設定とワークフロー (配色またはアイコンのテーマ、キー バインド、エディター生産性向上機能など) をサポートするあらゆる拡張機能を引き続き使用できるようにすることが重要です。
さらに、高い生産性を維持しながら、コラボレーション セッションに参加する動作をできるだけ迅速するため、Visual Studio Live Share の目標は、ホストが共有しているプロジェクト固有のツールをゲストが自動的に利用できるようにすることです。 このようにして、リンクをクリックするだけで、ご自分で選択したツールを起動し、共同作業を開始できます。追加の設定は必要ありません。 これを実現するには、中核の編集、ビルド、デバッグのワークフローを強化する拡張機能がホストからゲストに透過的に "リモート処理" され、オートコンプリート、定義元への移動、デバッグなどが "正確に機能する" ことが重要です
このドキュメントでは、大規模な拡張エコシステムの現在の既知の状態と、前述の目標の "スコアカード" について説明します。 この条件を満たしていない拡張機能を見つけた場合で、それがご自分のワークフローにとって重要である場合は、お知らせください。
ユーザー固有の拡張機能
ユーザー固有のカスタマイズをサポートする拡張機能は、ホストに対して機能する必要があり、すべてのゲストに対して動作する必要があります。 拡張機能がホストに対して正しく機能しない場合、それは回帰であり、Visual Studio Live Share のバグであるおそれがあります (問題を見つけた場合は、イシューを申請してください)。 拡張機能が、ゲストに対して予期したとおりに動作しない場合は、拡張機能自体の変更が必要になることがあります。また、このようなシナリオに対処して改善するために、Microsoft はエコシステムを操作します。
Visual Studio Code
カテゴリ | 例 | ゲストに対するサポート | コラボレーションの可否 |
---|---|---|---|
配色テーマ | One Dark Pro、Output Colorizer、Rainbow String、Colored Regions、Indented Block Highlighting、Todo Highlight、Bracket Pair Colorizer | ✅ | N/A |
アイコン セット | vscode-icons、Visual Studio Classic Icons | ✅ | N/A |
キー バインド | Vim、IntelliJ IDEA Keybindings、Emacs Friendly Keymap | ✅ | N/A |
スニペット | Angular v5 Snippets、HTML Snippets、SVG Icons、File Header | ✅ | N/A 1 |
組織 | Settings Sync、Project Manager、Timeit、Checkpoints、TODO Parser、Favorites (❌)、Bookmarks (❌) | ✅2 | N/A 3 |
生産性 | GitLens、Auto-Rename Tag、Code Outline、Color Highlight、Increment Selection、Bracketeer、Image Preview、JSON Helper (Hover)、Color Picker、Copy Word in Cursor、CodeMetrics (CodeLens)、Git Co-Authors、JavaScript Booster (CodeActions)、Turbo Console Log、Goto Next/Previous Member、Auto-scroll、NPM Import Version (❌)、Import Cost (❌) | ✅2 | ❌3 |
REPL | REST Client、Code Runner、Quokka.js、R | ✅4 | ❌3 |
Resource Manager | mssql、ftp-simple、Azure Functions、Docker、Brew Services | ✅5 | ❌3 |
1 ユーザーが既にスニペットを使い慣れていない場合は、それらが使用可能になることは期待されないため、共有することが必ずしも有意義であるとは言えません。
2 これらの拡張カテゴリは多様であり、すべての機能が動作するとは限りません。しかし、理論的には、動作するはずなので、そうではないキーを追跡します。
3 これらの拡張機能のカテゴリは、共同作業のエクスペリエンスの恩恵を受ける可能性があるため、それを知るためにエンドユーザーの皆さんからのフィードバックが必要です。
4 これらは、ゲストにランタイム ツールがインストールされていて (例: Node.js)、コードをローカルで実行することで機能する必要があります。
5 これらは、何らかのサーバーに接続することによって機能し、中央サーバー、ゲストが共有しているサーバーのどちらでも使用できます。
プロジェクト固有の拡張機能
ホストにインストールされた拡張機能は、アプリケーションの主な編集、ビルド、デバッグをサポートし、言語/プラットフォーム/ライブラリ/SDK に固有のものである必要があります。ゲストは、何もインストールする必要はなく、自動的に利用することができます。 このように、ホストは、プロジェクトの生産的な開発をサポートするように環境を設定し、追加の前提条件なしでゲストが即座に参加できるようにすることができます。 プロジェクト固有の拡張機能は主観的でも個人的でもありません。そのため、ユーザーの使い慣れた環境に影響を与えることなく、ホスト間で確定的に共有することができます。
さらに、ゲストがインストールしたが、ホストはしていないプロジェクト固有の拡張機能をサポートするために、理想的には、機能が低下していても機能的なエクスペリエンスを提供します (1 つのファイルの intellisense を取得する、ドキュメントをフォーマットできるなど)。
カテゴリ | 例 | 共有 | ゲストに対するサポート |
---|---|---|---|
文法/構文の強調表示 | Fish Shell、Nginx、Vetur、DotEnv、ES6 String HTML、Todo+、Rainbow CSV | ❌ | ✅ |
言語サービス | YAML、Path Intellisense、ARM | ✅1 | ✅2 |
JSON スキーマ | Azure Functions | ✅ | ✅ |
リンター | ESLint、Markdownlint、Code Spell Checker、PHPCS | ✅ | ✅2 |
フォーマッター | Prettier、Beautify | ✅ | ✅2 |
デバッガー | Python、Debugger for Chrome | ✅3 | ❌4 |
テスト ランナー | Java Test Runner、Mocha Sidebar、Jest Runner、Neptune | ❌5 | ✅2 |
カスタム ファイル プレビューアー | SVG Preview、GraphViz、Markdown Image Size | ❌ | ✅ |
ファイル/プロジェクト ジェネレーター | Azure Functions、C/C++ Project Generator | ❌ | ❌6 |
ソース管理プロバイダー | SVN、Hg | ❌ | ❌ |
1 現在、C# と JavaScript/TypeScript のみ。
2 ゲストがローカル ファイルにアクセスできないため、現在のアクティブなドキュメントだけをサポートします。
3 コア デバッグ エクスペリエンスは共有されますが、起動されたサーバーは自動的には転送されません。
4 ゲストはアプリのローカル コピーを持っていないため、実行中のアプリとデバッグ セッションをホストのコンピューターで起動する必要があります。
5 テストの実行の出力では、結果として得られるすべての端末、出力ペイン、エラーもゲストと共有される必要があります。
6 ほとんどの場合、Node.js モジュールを直接使用して fs
ファイルを作成します。これは機能しません。
既知の問題
現在の、拡張機能の既知の問題を次に示します。これらが原因で、コラボレーション セッション (およびその回避策と共に) のコンテキスト内でゲストが作業できなくなり、ワークフローに影響を与えるおそれがあります。
Visual Studio Code
問題 | 理由 | 回避策 |
---|---|---|
Node.js fs モジュールを使用したファイルの検出/読み取り (構成ファイルなど)、またはディレクトリの列挙 (言語サービスではない場合)。 |
ゲストにはローカル ファイル アクセスがありません。 | 1. ユーザー エクスペリエンスを適切に低下させます "(可能な場合)"。 2. openTextDocument および findFiles workspace API を使用して、ファイルの読み取りと列挙を行います。 |
Node.js fs モジュールを使用したファイルの作成または書き込み |
同上 | 該当なし openTextDocument(Uri) API を使用して untitled ファイルを作成することはできますが、特定のパスでファイル システムに直接保存することはできません。 |
プロジェクトバンドルのライブラリまたはツールへの依存 | 同上 | 1. 依存関係のフォールバック バージョンを拡張機能とバンドルします 2. 明示的にインストールする場合は、ゲストのブロックを解除するグローバル インストールをサポートします。 3. 可能であれば、状態/アクションをリモートで実行します。これは、ホストは適切な依存関係を利用可能であるためです。 |
Node.js fs モジュールを使用したディレクトリの作成 |
同上 | N/A |
file スキームを使用するドキュメントに対する機能の制限。 |
ゲスト側のファイルは、vsls スキームを使用します。 |
vsls ドキュメントのサポートを追加します (例) |
Uri.file メソッド、および/または Uri.fsPath /TextDocument.fileName メンバーを使用した URI のシリアル化または解析 |
同上 | 代わりにファイル スキーマを維持し、考慮する Uri.parse と Url.toString() を使用します (例) |
Uri の代わりにファイル パスで workspace.openTextDocument メソッドを使用する |
同上 | 生ファイル パス文字列の代わりに Uri インスタンスを指定する (例) |
workspace.rootPath プロパティを使用してワークスペースの存在を検出する |
workspace.rootPath プロパティにより、前述したのと同じ問題がある workspace の最初の workspaceFolder で Uri.fsPath が呼び出されます。 |
代わりに、workspace.workspaceFolders プロパティを使用してワークスペースの存在を検出します。必要に応じて、各 workspaceFolder の Uri.scheme を調べて、ローカルであるかどうかを確認します。 |
言語サービスを登録するときにドキュメント スキームが指定されない (LanguageClient または languages.register* メソッドを使用) |
ゲストは、ローカルの拡張機能とホストの両方から言語サービスの結果を受け取ります。したがって、両方の参加者が同じ言語サービス拡張機能をインストールしている場合、ゲストには、特定の項目 (オートコンプリート、コード アクションなど) について重複するエントリが表示されます。 | 言語サービスを file と untitled スキームのみに制限します (例) |
ドキュメントの Uri.scheme を確認せずに DiagnosticCollection が設定される |
同上 | documents の Uri.scheme === file にのみ Diagnostics を作成します (例) |
カスタム TaskProvider から戻るときに Tasks ワークスペース スキームが確認されない |
ゲストにはリモートタスクとローカルタスクがすべて表示されるため、両方の参加者が同じ拡張機能をインストールした場合は、重複した内容が表示されます。 | Tasks が返される WorkspaceFolder のは、Uri.scheme === file だけです (例) |
関連項目
問題が発生していますか? トラブルシューティングまたはフィードバックの送信に関するページをご覧ください。