Atomパッケージをアンパブリッシュする

Wed, Dec 2, 2015
atom
Atomパッケージをアンパブリッシュする

Table of Contents


Atomのパッケージをリリースすることをパブシッシュというが、リリースを取り消すことをアンパブリッシュという。 この記事はそのアンパブリッシュのやり方などについて。

筆者の環境は以下。

  • Windows 7 x64
  • Atom 1.2.4
  • Git for Windows 2.6.3


アンパブリッシュのやり方

リリースしたパッケージのプロジェクトのルートフォルダ(package.jsonがあるところ)にcdして、apm unpublishを実行するだけ。

または、任意のフォルダでapm unpublish <パッケージ名>を実行する。

特定のバージョンだけアンパブリッシュしたい場合は、apm unpublish <パッケージ名>@<バージョン>。例えばapm unpublish [email protected]。

注意すべき点 1: Git Bashでアンパブリッシュするとエラー

Git for WindowsのGit Bash上で、Windows版Atomに付属するapmでapm unpublishを実行すると以下のエラーが出る。

Error: EINVAL, invalid argument
    at new Socket (net.js:157:18)
    at process.stdin (node.js:693:19)
    at Unpublish.module.exports.Unpublish.promptForConfirmation (C:\Users\Kaito\AppData\Local\atom\app-1.2.4\resources\app\apm\lib

\unpublish.js:87:48)
    at Unpublish.module.exports.Unpublish.run (C:\Users\Kaito\AppData\Local\atom\app-1.2.4\resources\app\apm\lib\unpublish.js:126:21)
    at Object.module.exports.run (C:\Users\Kaito\AppData\Local\atom\app-1.2.4\resources\app\apm\lib\apm-cli.js:226:32)
    at Object.<anonymous> (C:\Users\Kaito\AppData\Local\atom\app-1.2.4\resources\app\apm\lib\cli.js:6:7)
    at Object.<anonymous> (C:\Users\Kaito\AppData\Local\atom\app-1.2.4\resources\app\apm\lib\cli.js:17:4)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)


コマンドプロンプトでやるべし。

注意すべき点 2: アンパブリッシュはパブリッシュの真逆じゃない

以前の記事で apm publishは以下の処理をすると書いた。

  1. (初回のみ)パッケージ名をatom.ioに登録する。
  2. package.jsonのversionをインクリメントしてコミットする。apm publishにminorを指定するので、0.1.0になる。代わりにmajorかpatchを指定すると、1.0.0か0.0.1になる。
  3. Gitのタグを作る。
  4. GitHubに変更とタグをpushする。
  5. atom.ioにパッケージを登録する。

この内、apm unpublishが取り消してくれるのは 5 だけ。

3, 4 のタグ作成も取り消したいのであれば、

$ git tag -d v0.1.0
$ git push origin :v0.1.0

のようにして、ローカルリポジトリとリモートリポジトリ両方のタグを削除する。

また、2 のpackage.jsonのversion変更を取り消したいのであれば、git logでPrepare 0.1.0 releaseみたいなログのコミットをさがしてそのハッシュをメモり、

$ git revert <ハッシュ>

を実行してgit push。(上記<ハッシュ>の部分は、apm publish後何もcommitしてないならHEADでもよし。)

注意すべき点 3: パッケージのキャッシュ

とあるパッケージ、仮にhogeを開発していたとき、以下のような操作をした後に変な現象が起こった。

  1. バージョン0.1.0をパブリッシュ。
  2. hogeをちゃんとインストールできるかを確認するために、
    1. apm unlink hogeで.atom\packagesからリンクを削除。(以前、パブリッシュすると.atom\packagesにはパッケージの実ファイルが入ると書いたが、リンクのままだった。勘違い?)
    2. AtomのSettingsからhogeをインストール。
  3. ちゃんとインストールできなかったのでapm unpublish hogeして、バージョンも戻す。
  4. hogeを修正して、再度0.1.0としてパブリッシュ。
  5. hogeをちゃんとインストールできるかを再度確認するために、
    1. apm unlink hogeして、
    2. AtomのSettingsからhogeをインストール。

これをしたら最終的になぜか修正前のhogeがインストールされた。 どうやらキャッシュがある模様ということで、apmのソースをみたら、パッケージのインストール中に以下のようなことをしていることがわかった。

  1. AtomのサイトのREST API (https://www.atom.io/api/packages/hoge/) からパッケージ情報を取得。
  2. また別のREST API (https://www.atom.io/api/packages/hoge/versions/0.1.0/tarball) を実行して、パッケージのアーカイブ(tar.gz)をテンポラリフォルダにダウンロード。 どうもこれは実際にはGitHubのReleasesからダウンロードしている模様。 因みにGitHub Releasesのアーカイブは、リポジトリにタグが追加されると自動で作られる。
  3. npm installでそのアーカイブを指定してインストール。

この手順の 2 をやる前に、.atom\.apm\hoge\0.1.0\package.tgzを探して、見つかるとダウンロードせずにこっちをインストールする。 ソースの雰囲気から、.atom\.apm\に入っているのはキャッシュのようで、いつ作られるかはよくわからないが、これが上記変な現象の原因ぽい。

ということで、.atom\.apm\hoge\0.1.0\package.tgzを消して再度インストールしたら無事修正後のhogeが入った。


このキャッシュの件や、apm unpublishがパッケージのバージョンを戻さないところをみると、同じバージョンを再度パブリッシュするのはダメな操作なのかもしれない。 修正したかったらバージョンを上げろということなのかも。