トラストバンクのフロントエンドエンジニア、田口です。
ずいぶん暖かくなってきましたね。でも花粉が舞っているので毎日家にこもってエルデンリングをやってます。神秘マンです。
さて今回は既存のnpm scriptが動かなくなったときの話になります。かなり初歩的な内容ではありますが、環境によっては気づきにくい落とし穴かもしれません。
前提
ふるさとチョイスの一部コンテンツではejsを使用しており、そのコンテンツのhtmlをビルドするためにnpm scriptでgulp(と、そのプラグイン)を使っています。
htmlをビルドする際、jsonで作成しているコンテンツデータを取り込み、ejsに流し込んで最終的なhtmlにしています。
該当のnpm scriptは自分を含めた何人かの手が入っており、利用した人も複数いますが、これまでで異常は発生していませんでした。
唯一のWindowsユーザーで発生したエラー
弊社のエンジニアの多くはMacユーザーなのですが、Windowsユーザーにejsの変更作業をお願いしたところ、ejsのビルドに失敗しました。
そのWindowsユーザーはWSLを使用しておらず、Git bashを使っていました。
ログを出力してもらいながら調査していたところ、以下の箇所でエラーになっていました。
data.page = file.path.split('src/ejs/')[1].replace('.ejs', '.html').replace('index.html', '');
内容としてはパスを文字列として置換をかけているような処理です。
何がおかしいのか。file.path
には文字列のファイルのパスが入っていますが、それをMac(POSIX)とWindowsで比較すると、
'/your/directory/something.html' // Mac 'C:\\your\\directory\\something.html' //Windows
このように、ディレクトリの区切り文字が異なっていました。
解決策
色々試してみましたが、お手軽なPath.sep
*1を使用する形に変更しました。
data.page = file.path.split('src' + path.sep + 'ejs' + path.sep)[1].replace('.ejs', '.html').replace('index.html', '');
その他のパスを文字列として扱っている箇所も同じように変更して、エラーは発生しなくなりました。よかった!
やはりWSLか…
今回ハマった箇所としてはPOSIXとWindowsの違いだったのですが、Node.jsだけでなく、様々な面でWSLの使用をお勧めすべきなのだと改めて感じました。
Node.jsに関して言えば、Windowsで引っかかる点は幾つもあります。*2
Windowsユーザーを考慮してコードを書くのも一つの手ですが、やはりWSLを使用する方向で開発組織として統一してしまうのがベストなのだと思います。
ということで今回はあっさりとここまでです。お疲れ様でした。
いつもの
トラストバンクではnpm scriptによってフロントエンドの開発効率をグングン向上できるような、開発環境整備にも強いエンジニアを募集しております! www.wantedly.com