VSCode拡張機能をOpen VSX Registryにpublishする

ファイル編集にAntigravityを使っているが、VSCodeと拡張機能のマーケットプレイスが異なる。

エディタ マーケットプレイス
VSCode Visual Studio Code Marketplace
Cursor Open VSX
Antigravity Open VSX（設定で切り替え可能）

Open VSX Registryへの公開は以下の手順でおこなえばいいが、若干詰まったので備忘。
https://github.com/eclipse/openvsx/wiki/Publishing-Extensions

アクセストークンを作成

  • Eclipseアカウントを作成する
  • Eclipse Contributor Agreementに同意する
  • OpenVSX RegistryにEclipseアカウントでログインする
  • ProfileタブでOpen VSX Publisher Agreementに同意する

Publisher Agreementの同意ボタンが中々見つからず右往左往したが、 Contributor Agreementに同意した上でログインし直したら見つかった。

これでアクセストークンが作成出来るようになる。

Publish

最初に package.json#publisher と一致するnamespaceを作成する。

npx ovsx create-namespace <name> -p <token>

publishコマンドで、ビルドして公開する。

npx ovsx publish -p <token>

namespaceのclaim

このままだとpublisherの認証マークがつかないので、以下の通りOpen VSXリポジトリにIssueを立てて申請する。
https://github.com/eclipse/openvsx/wiki/Namespace-Access#how-to-claim-a-namespace

ブラウザまわりの操作をskhdでホットキーに割り当てる

普段の業務でよく使う操作がある。

私の場合は、

  • URLをコピーして、ブラウザ（chrome）で開く
  • ブラウザ（chrome）のタブを複製する
  • ブラウザ（chrome）のブックマークを検索して別タブで開く

といった操作をすることが多い。

単純な操作ではあるが、複数のキー入力が必要なので地味に面倒だったりする。

そんな時ホットキーを柔軟に設定できるskhdを使うと便利という話。

skhdでホットキーを設定する

skhdは任意のホットキーを設定できるソフトウェア。つまり任意のキー入力を別のキー入力や処理にマッピングすることが出来る。

https://github.com/koekeishiya/skhd

先ほどの操作をホットキーにするとこんな感じになる。

# URLをコピーして、デフォルトブラウザで開く
rcmd - t : open (pbpaste)

# ブラウザ（chrome）のタブを複製する
rcmd - d : skhd -k "cmd - l"; skhd -k "alt - return";

# ブラウザ（chrome）のブックマークを検索して別タブで開く
rcmd - b : skhd -k "cmd -t"; skhd -k "cmd - l"; skhd -t "@bookmarks"; skhd -k "tab";

右コマンドに割り当てる

どのキーで発火させるかだが、以下の理由で私は右コマンドに割り当てている。

  • 普段使わないので余っている
  • 既存のホットキーやショートカットと衝突しにくいのでパターンを設定しやすい
  • 自作のホットキーは右コマンドで発火すると頭で考えやすい

ちなみに右コマンド単体はKarabiner Elementsで日本語入力にする設定を入れているが、これとも衝突せず問題なく動作する。

まとめ

  • よく使う操作をskhdでホットキーに設定すると便利
  • 右コマンドに割り振るのがおすすめ

package.jsonのmainとexports

エントリーポイントを表すmainとexports

パッケージのエントリーポイント指定には今までmainフィールドを使用してきた。

{
  "main": "./dist/index.js"
}

これは今でも有効な指定であるが、単一のエントリーポイントしか指定できないため、利用者側の形式（CommonJS形式とESModule形式）で分岐できない。

現代ではブラウザ環境およびNode環境でもESModuleが普通に使えるので、ESModule形式だけでも大分問題なくなってきたが、とはいえライブラリとして配布する時はCommonJS形式のサポートが必要なことが多い。

exportsはNode.js 12から追加された機能で、条件によってエントリーポイントを分岐することが出来る。

{
  "main": "./dist/index.js",
  "exports": {
    // 利用する側がESModule環境のとき
    "import": "./dist/index.js",
    // 利用する側がCommonJS環境のとき
    "require": "./dist/index.cjs"
  }
}

exportsとmainがどちらも指定されている場合はexportsが優先される。 基本的にexportsはmainの上位互換的な機能なので通常はexportsだけで良いが、古いNode.js環境用にmainも指定しておくのが良さそう。

exportsのメリット

exportsは定義したパスのみ公開できる。 これにより、定義していないパスでのインポートをエラーにすることが出来る。

{
  "name": "my-package",
  "main": "./dist/index.js",
  "exports": {
    ".": "./dist/index.js",
    "./client": "./dist/client/index.js"
  }
}

// ok
import { xxx } from 'my-package';

// ok
import { yyy } from 'my-package/client';

// error (ERR_PACKAGE_PATH_NOT_EXPORTED)
import { yyy } from 'my-package/server';

参考