※スマホ対応はしてません。

カテゴリー: 開発環境

npm installがENOENTとか変な失敗をするとき、VS Codeを閉じると良いかも。

カテゴリー: 開発環境

Windows/WSL1 + Ubuntu + VS Code という組み合わせでやってるんですが、しばしば npm install が失敗します。

npm ERR! code ENOENT
npm ERR! syscall rename
npm ERR! path /mnt/c/Users/ginpei/xxx/node_modules/@typescript-eslint/typescript-estree/node_modules/semver
npm ERR! dest /mnt/c/Users/ginpei/xxx/node_modules/@typescript-eslint/typescript-estree/node_modules/.semver.DELETE
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, rename '/mnt/c/Users/ginpei/xxx/node_modules/@typescript-eslint/typescript-estree/node_modules/semver' -> '/mnt/c/Users/ginpei/xxx/node_modules/@typescript-eslint/typescript-estree/node_modules/.semver.DELETE'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent 

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/ginpei/.npm/_logs/2020-09-30T18_57_36_471Z-debug.log

なんか一時ファイルっぽいし謎ですね。

原因はよくわかってないんですが、どこか(どこだっけ)で「VS Code のファイル監視が悪さをしている」ような話を聞いたことがあって、実際 VS Code を閉じた状態でこういうエラーに出くわしたことはないです。

というわけで VS Code を閉じてみてください。

  1. VS Code を閉じる
  2. VS Code 以外のターミナルから npm install
  3. 完了したら、VS Code を開く

Error persisting state: EACCES: permission denied, rename

他のパターンも置いておきます。これは npm install じゃなくて Gatsby のビルドで出てきたやつ。

warning Error persisting state: EACCES: permission denied, rename '/mnt/c/Users/ginpei/xxx/.cache/redux' -> '/mnt/c/Users/ginpei/xxx/.cache/redux.bak'

対処は同じく VS Code を閉じてください。

[Windows] VS Code を閉じた状態でターミナルを利用する

VS Code 内のターミナルで実行しているのに VS Code を閉じるとそのまま npm install も終了してしまうので、他のターミナルが必要です。

  1. cmd.exe … Windows 標準の黒い画面。wsl コマンドとかで WSL を開く
  2. Windows Terminal … Microsoft 謹製のターミナルアプリ。複数タブ等、諸々便利でおすすめ
  3. tmux … Linux 内で動くターミナル多重化アプリ。一言で言うと「閉じても終了しないセッションを作る」ことができる

tmux が一番便利だけど CLI に慣れてないとつらいと思うので、一般には Windows Terminal をお勧めしておきます。いずれにしろ入れておいて損はないです。

おしまい

「VS Code のファイル監視が~」の件、ちゃんとした情報源があれば教えてください。

WSL2をインストールしてDocker使ったりUbuntuを変換したり戻したりした。

カテゴリー: 開発環境

これまでも WSL を愛用していたんだけどいよいよ WSL 2 が来たようなので、入れてみました。そんで戻しました。

ちなみに WSL の 1 と 2 はそれぞれ長所短所ある別の仕組みであるらしく、同じ Windows 機に同時にインストールできるみたいです。Docker 使うなら 2 が必要。

本記事の内容

  • WSL 1 を利用中が前提
  • WSL 1 の環境を 2 へ変換する
  • WSL 2 の環境を 1 へ戻す
  • デフォルトで 1 で使うか 2 で使うかの設定
  • Docker は Docker Desktop を使うよ

Windows Terminal

本件とは直接関係ないんだけど、すっげー便利なのでおすすめです。このアプリひとつで Power Shell もコマンドプロンプトも、ついでに WSL で動いてる Linux シェルも開けます。

WSL 2 の用意

Windows バージョンの確認

Windows の設定 (Win+I) → System → About → Windows Specifications を開いて、”Version” の項を確認してください。(最初から version とかで検索しても出てくるはず。) これが最新の 2004 (かそれ以上)である必要があります。

まだなら Windows を更新

OS の Windows Update の画面から更新を何度確認しても降ってこなかったので(そういうものなの?)、インストーラーを探してインストールしました。こちらから。

URL 的に将来再利用されそうだけれど、現時点では最新版 “Windows 10 May 2020 Update” がダウンロードできます。このファイル自体はダウンローダー?なので一瞬で終わるんだけど、それを起動して更新をダウンロード、インストールするのに 30 分くらいかかりました。ほげえ。

なお最新の状態でこのインストーラーを起動しても「今最新版だよ~」と教えてくれるだけなので無害です。

ただし人によってはこれでインストールできない場合もあるらしい。どういうんだろう。

Virtual Machine Platform を有効化

管理者権限で PowerShell を開き、以下を実行します。

> dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

1 分くらい?

カーネルをインストール

この “Download the Linux kernel update package” の節から wsl_update_x64.msi をダウンロード、実行。

Windows Subsystem for Linux Update Setup のウィンドウ

更新はウィザードでぽちぽちするだけ。

WSL 2 を使う

(任意)デフォルトで WSL 2 を利用するように

WSL 1 と 2 を併用できます。Microsoft Store とかでダウンロードした Linux ディストロをインストールするときの初期値をそのどちらにするか設定できるようです。

2 にするなら、こう。

> wsl --set-default-version 2
For information on key differences with WSL 2 please visit https://aka.ms/wsl2

利用中の WSL 1 を 2 へ変換

一覧から名前を得て、その名前を対象に更新します。

まずは一覧を表示して、名前を得ます。この例では “Ubuntu” ですね。

> wsl --list --verbose
NAME STATE VERSION
* Ubuntu Stopped 1

この名前 “Ubuntu” を覚えておく。

続いて --set-version します。

> wsl --set-version Ubuntu 2
Conversion in progress, this may take a few minutes...
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
…

数分かかるとのことだが 60 分経っても終わりませんでした。ま、まただましたな!

完了したらバージョンが上がったのを確認。

> wsl --list --verbose
NAME STATE VERSION
* Ubuntu Running 2

使う

あとは普通に使うだけ。やったね。

やっぱり戻す

WSL 側から Windows 側ファイルの監視があやしい。

/mnt/c/User/ginpei 下にプロジェクト配置してるんだけど、どうも watch が怪しい感じがする。かつて普通の VM (VirtualBox) を使ってた頃も同じような問題に直面したような。

新機能は別途試すとして、やっぱり今の環境はそのまま残しておこう……ということにしました。残念。

バージョンをまた変える

さっき WSL 1 → 2 にしたのと同じ手順で 2 → 1 へ変換します。

> wsl --set-version Ubuntu 1

はいこれで元通り。こっちの変換の方が所要時間が少ない様子。

変換にかかる時間

対象は新規にダウンロード、インストールした空っぽの Ubuntu 20.04 LTS です。空っぽだと変換が速いみたい。

WSL のデフォルトを WSL 2 にしているので、2 → 1 → 2 の順番に変換してます。

2 → 1

1 分。

> Measure-Command { wsl --set-version Ubuntu-20.04 1 }

Days : 0
Hours : 0
Minutes : 0
Seconds : 49
Milliseconds : 284
Ticks : 492840008
TotalDays : 0.000570416675925926
TotalHours : 0.0136900002222222
TotalMinutes : 0.821400013333333
TotalSeconds : 49.2840008
TotalMilliseconds : 49284.0008

1 → 2

4 分。

> Measure-Command { wsl --set-version Ubuntu-20.04 2 }

Days : 0
Hours : 0
Minutes : 3
Seconds : 42
Milliseconds : 670
Ticks : 2226708369
TotalDays : 0.00257720876041667
TotalHours : 0.06185301025
TotalMinutes : 3.711180615
TotalSeconds : 222.6708369
TotalMilliseconds : 222670.8369

WSL 1 vs 2

表を翻訳して転載。

機能 WSL 1 WSL 2
Windows と Linux の統合
高速起動
省サイズ
Managed VM
完全な Linux カーネル
完全なシステムコール互換性
現行版の VM Ware や VirtualBox と併用
OS のファイルシステム越しのパフォーマンス

(Managed VM って何? 本当の VM だよって意味?)

感覚的には、こんな感じ↓かなと思ってます。正しいですか?

  • WSL 1 は Windows のまま Linux のコマンドを動かす(Cygwin や MinGW みたいな)
  • WSL 2 は Windows とは別に Linux VM を動かす(VM Ware や VirtualBox みたいな)
  • あと、 2 は Windows 10 Home でも使える

Docker

動くようになりました。Windows 側に Docker をインストールする必要があります。

Docker がサポートしたのは WSL2 上の Linux ではなく「WSL2 バックエンド」だそうで、つまり Docker Desktop for Windows を経由してコンテナーを WSL2 の仕組みで実行させる、というものであるらしい。……これで合ってる?

Docker を使う流れ

なので、こんな流れ。

  1. WSL2 準備(本稿)
  2. Docker Desktop インストール
  3. WSL 2 のインスタンスから docker run hello-world

さっくり動きました。

エラー

管理者権限が必要

Power Shell なり何なりを普通に起動すると、権限を elevate してねと言われます。管理者権限で起動してください。

>dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Error: 740

Elevated permissions are required to run DISM.
Use an elevated command prompt to complete these tasks.

不明なオプション

メモ取り忘れたんだけど、WSL 2 の準備が終わってないと --set-version とか諸々が使えません。( wsl コマンド自体は存在する。)

順にやっていきましょう。

カーネルが古い

「不明なオプション」と同じ。まだ WSL 2 の準備が終わってません。『カーネルをインストール』の節を参照。

> wsl --set-default-version 2
WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel

Docker が使えない

WSL 全体の設定で、WSL 2 のディストロをデフォルトに設定しないといけないようです。はまった。

以下 Ubuntu で試したもの。

$ docker run hello-world
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.

Docker デーモンが動いてない? じゃあ動かそう。

$ sudo systemctl start docker
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

このエラー見たことある……。

おしまい

仕事は引き続き WSL 1 でやることにします。

とはいえ Docker 使ってやっていきをしたいところ。ファイル監視はな~どうしたら良いかな、気のせいであってほしいけど。

参考

更新履歴

  • 2020/11/24
    • Docker が動かないと思ってたけど動いてたので更新
    • (WordPress のエディターが替わって編集がうまくやれない……)
  • 2020/06/15 17:22
    • 初版公開

Neovim for Windowsでcolorschemeを置く場所は本体らへん。

カテゴリー: 開発環境

<Neovimインストール先>\share\nvim\colors に foo.vim を置いて、 init.vim で colorscheme foo する。ディレクトリはないので自分で作る。

ちなみにGUI版は <Neovimインストール先>\bin\nvm-qt.exe ね。

ちゃんとやらないとこんなエラー。

E185: Cannot find color scheme 'foo'

当たり前すぎるのか情報が見つからなかった。まあgvimもこんな感じだったっけな。

あんまり関係ないリンク

「Web製作者のためのGitHubの教科書」は非技術者におすすめの本です。

カテゴリー: 開発環境

著者の一人、平木聡さんから頂いてましたので、紹介させて頂きます。

GitHubは年中無休なので、お正月に本書を読みながら諸々を試しておくと、新年の業務がスムーズになるんじゃないすかねー。

概要

  • GitだけでなくGitHubだけの機能も紹介
  • GUIアプリ(SourceTree Win/Mac)とコマンドラインとの両方で作業を解説
  • 画像多数、ちなみに総天然色
  • 言い回しや書体、図解が読みやすい

    (さらに…)

最初にドキュメントから書く話。(JavaScriptおれおれAdvent Calendar 2014 – 17日目)

カテゴリー: 開発環境

JavaScriptおれおれAdvent Calendar 2014 – 17日目

特にライブラリー的なものを作るとき、最初にドキュメントを書くようにしてます。

例えばこれ、まだドキュメントしかないです。

最初にドキュメントを書く効能

もちろん後で書く手間が省けるってのもあるけど、それより、最初にAPIのリファレンスを作る事で、成果物の最終形が明確になります。最終形が分かっていれば、ごりごり書いてそれに近づけるだけっすね。

APIが決まっていれば試験を書ける、試験が書ければリファクターができる、リファクターができれば雑なコードでも実装を進められる。とまあそんな感じ。

もしここで明確な最終形を記述できなかったとしたら、それは現時点ではまだ何を作れば良いかわかっていないという事になるでしょう。それだとコードも書けない。

モジュールでも同じように

製品内の部品を作る場合も、同じように最終形を最初に考えます。これはいちいちドキュメント作成したりはしない場面が多いけど、脳内には用意しておく。必要ならメモ書きくらいは作っても良い。

理由は前述のものと同じで、これから何を作るのかを確認するため。

書く内容

短い紹介文が欲しい。というかそれが一番大事だと思う。端的な紹介文はこれが「何であるか」だけでなく「何でないか」も表現し得るので、方向性を定めやすい。

あとはリファレンスと使用例。例は具体的な利用場面も想定できるとなお良し。

別に変更してもいい

実装コードを書いてから気付く(あるいは単純に思い出す)事もあるので、最初に作った仕様を厳守するというわけじゃないです。

あと十分に先が見えていないと最終形を定める事はできず、こういう形で作業を進めるのは無理ですね。そういうときは適当にそれっぽいものを作って、触って、捨てて作り直して、を繰り返す。新しい何かを作るときはそうなりがちだと思う。

ただ、思想については曲げずに進めたいなと。

まあ

言うほど毎回しっかりやってるわけでもないんだけど……。理想的な働き方みたいなもの。