「Node.js」の記事 - Crieit

Playwright のミニマムなテスト。

2023-02-04T02:06:05+09:00

Playwright とはなにか。

Selenium みたいなもの。
https://www.selenium.dev/

Puppeteer みたいなもの。
https://pptr.dev/
https://youtu.be/ARt3zDHSsd4?t=70

簡単に言うと、ブラウザを使って、javascript が動作することでページがちゃんと見えるうなうなサイトをスクレイピングしたりするのに使うプログラムのセットのようなもの。
ブラウザのプログラムが別に必要だが、パッケージマネージャーでインストールするタイプのものだと、セットでインストールすることもできる。

https://github.com/microsoft/playwright

Node.js と npm

前準備として node.js をインストールして、npm パッケージマネージャ―が使える状態にする。
以降は、 node.js のインストールが完了されている状態での操作になる。

node.js インストールの手順は省略
https://nodejs.org/ja/download/

Node.js をインストールすると npm パッケージマネージャーが使えます。
Node.js 向けのモジュールは npm パッケージマネージャーのコマンドでインストールします。
npm を使って、別のパッケージマネージャーをインストールすることができます。ですが、この記事では使用しません。

npm と node.js のバージョン。

npm -v
9.3.1

node -v
v19.5.0

ブラウザを立ち上げて手動で操作して、その過程をコードで記録する。 test & codegen

手動でページ移動などの操作をして、コードとして記録する。

https://youtu.be/wGr5rz8WGCE?t=130

前準備として node.js をインストールして、npm パッケージマネージャ―が使える状態にする。
https://nodejs.org/ja/download/

Playwright のインストール。chromium ブラウザーも同時にインストールされる。

npm i -D playwright

https://www.youtube.com/ を chromium ブラウザーで開いて、操作する。

 npx playwright codegen https://www.youtube.com/

chromium ブラウザーのウィンドウが２つ開いて、

ブラウザ上の操作が記録されていく。

手動でブラウザでテキスト入力したり、ボタンを押したりしたりしたことがコードとして記録されるので、このことを利用して、記録されたコードをコピーして自動処理のプログラムコードにペーストして編集すれば期待する動作のプログラムのコーディングに役立つ。

node.js での実行

javascript のプログラムファイルをつくり、Node.js で js ファイルを実行する。

https://www.youtube.com/watch?v=2_BPIA5RgXU&list=PLkiSKDHzztLAChyWRdYyFcIM-_yJTjrsR

まず、これから作るプログラムのプロジェクト用のディレクトリをつくる。

mkdir playw_test
cd playw_test

package.json

package.json というファイルを作って、そこにインストールしたいパッケージとバージョンを JSON 書式で書く。
https://www.startup-cloud.co.jp/liberty-technology/PublicItems/npm/package.json.html

package.json
https://rentry.co/5gm25u

{
    "devDependencies": {
        "playwright": "1.30.0"
    }

}

npm パッケージマネージャーで install コマンドを実行すると、package.json に記載されたパッケージがインストールされる。

npm install

playtest.js

https://rentry.co/zga9c


/**
* node.js から playwright での chrome ブラウザ操作テスト
**/

const playwright = require('playwright');

const url = "https://www.youtube.com/";

(async () => {
  const browser = await playwright.chromium.launch({
    channel: 'chrome',headless : false,
  });

  //context
  const context = await browser.newContext();
  //page
  const page = await context.newPage();
  //navigate
  await page.goto(url);
  var date = Date.now();
  //screenshot
  await page.screenshot({path: `${date}.png`});

  await browser.close();

  })();

気をつけないといけないのは、メソッド全てに awaitキーワードをつけないと、そんなメソッドはないですというそっけないエラーになるので、await を忘れるとあるはずのメソッドが無いということでどこで何がおかしいのかわからなくなる。

Node.js での実行。

playtw_test> node ./playtest.js

コマンドを実行して playtest.js が実行されると、ブラウザが立ちあがり、サイトに移動して、スクリーンキャプチャを保存して、ブラウザが閉じる。

test

playtw_test> playtest_2.js
https://rentry.co/2iui8

const playwright = require('playwright');

let url = ``; 
for( i = 2;i < process.argv.length; i++) {
  url = process.argv[i] ;
}

(async () => {
  const browser = await playwright.chromium.launch({
    channel: 'chrome',headless : false,
  });

  //context
  const context = await browser.newContext();
  //page
  const page = await context.newPage();
  //navigate
  await page.goto(url);

  await page.getByPlaceholder('検索').click();
  await page.getByPlaceholder('検索').fill('鳥インフルエンザ');
  await page.getByPlaceholder('検索').press('Enter');
  await page.waitForTimeout(1000);
  //screenshot
  var date = Date.now();
  await page.screenshot({path: `${date}.png`});

  await browser.close();

  })();

playtest_2.js を node.js で実行。

playtw_test> node ./playtest_2.js http://www.youtube.com/

AIイラストもOKの依頼サイトをつくってる

2023-01-19T02:53:19+09:00

タイトルの通りAIイラストもOKのイラストお題箱サイトを開発しています。そろそろ1ヶ月が経ちますがまだ完成しません。

https://prompton.io

↑ 既に投稿機能とリクエスト機能が使えるので遊びに来て！

AIイラストとは？

ここ数ヶ月で、HolaraAIやMidjourney、NovelAIなど色々な学習モデルが登場しており、各モデルもバージョンを上げて日々進化しています。最近ではカメラで撮った写真のような画像も生成できます。

例えばこれは海底をイメージした画像を生成しました。

漫画のコマのようなイラストも生成できます。実際にAI漫画を公開したり売ってる人もいます。

好みですが、少し画質の悪いアニメのような画像も。

逆に落書きのような画像を生成することもできます。用途は不明です。

何に使える？

AIイラストを使えば、例えば、サイトや小説の挿絵がたくさん作れます。ポスターにも使えそうです。

https://prompton.io/about

↑ このページの挿絵は全て「にじじゃーにー」で生成しています。

アイコンにも！

それからYouTubeやTwitterのアイコンも作れます。

もっとシンプルなアイコンも作れます。

プロンプトに「selfie」を含めると自撮りみたいなアイコンも作れます。

バッグや服も

デザインの知識がある人なら服やバッグのデザインもできるかもしれません。

自分はミニバッグがよく分かってないのですが、これは適当に作ってみた画像です。

これは適当に作った中学生が着てそうな服です。

今後は？

こういったAIツールや学習モデルは、毎日のように新しいものが公開されています。これからアニメだったり3Dモデルだったりの生成も可能になってくると勝手に予想しています。

https://huggingface.co/gsdf/Counterfeit-V2.0

↑ 最近だとこれ凄いアニメっぽい

一眼レフからスマホカメラになってライトユーザが増えたように、絵本や漫画やアニメ、カードゲーム、ボードゲームといった創作がもっと身近になると感じてます。

アイデアはあるけど時間がないって人はぜひAIイラストを触ってみてください。

リクエストして！

今のところ、AIイラストだけでも、GPUの購入、プロンプトの組み合わせ、学習モデルの選定、マージモデル、Pythonでのコーディングなど、そこそこ難易度はあがります。

そこで商用利用が可能なイラストを1枚500円からリクエストできるサイトを開発しています。

AIイラストは複雑な要望に向いていないのでココナラのような業務委託には向いていませんが、代わりに短期間で沢山つくって納品することができます。500円x4枚 = 2000円のようなリクエストもできます。

無償リクエストの場合は、納品された画像は商用利用はできませんがアイコンなど好きに使えます。

そのほか

こちらのユーザにもリクエストできるので、気になるからは見てみてください。

https://prompton.io/9Gjz1zJZS1M41ddmaU7aFU1HNqC2

↑ かわいいアイコンはこちらに

https://prompton.io/OMO61PwlcBWx5CVlVepXGP5U0gT2

↑ ロゴみたいなイラストはこちらに

https://prompton.io/5FlXKGvMsSNi9QiyNTqkG2tFEmF3

↑ 女性向けのかっこいいイラストはこちらに

https://prompton.io/OltOK5T6sZOuhVNay323tZkD2J32

↑ カードゲームのようなかっこいいイラストはこちらに

【node/yarn】asdfでnodeをインストールし、Yarnもつかえるようにする

2022-08-13T18:55:09+09:00

こんにちは、しきゆらです。

今回は、こちらで紹介したasdfを使ってNode.jsをインストールし、個人的によく使っているYarnも使えるように環境を作っていきます。

なお、Node.jsのインストールはすぐ終わったのですがYarnのインストールとか諸々に至るまでに紆余曲折ありました。まずは、インストールして環境構築までの流れをまとめます。

その後に、紆余曲折部分をメモしておきます。
必要なコマンドだけよこせ！という方は、以下の「環境構築の流れ」を参考にしてみてください。

環境構築の流れ

コマンド自体の使い方等はそれぞれのツールのサイト等で確認してください。

# node用のプラグインを追加
asdf plugin add nodejs

# nodeをインストール
asdf install nodejs latest

# システム全体で使うバージョンを指定
asdf global nodejs latest

# yarnを使う準備
corepack enable

# asdfの再構築
asdf reshim nodejs

これにて、環境構築は終了です。

yarnの手順が以前とだいぶ変わりましたが、npmで個別にインストールせずにパッケージマネージャを管理する仕組みが入ったようです。
そのおかげで手順がさっぱりしました。

では、前述の通り環境構築の紆余曲折や各ドキュメントを見ながらの細かい話は以下にまとめていきます。

環境構築の紆余曲折

Nodeのインストール

こちらは、asdfの仕組みにのっとって進めるだけなので、前回の記事と同じ手順を踏むだけです。

# node用のプラグインを追加
asdf plugin add nodejs

# nodeをインストール
asdf install nodejs latest

# システム全体で使うバージョンを指定
asdf global nodejs latest

# 確認
node -v

corepackについてもう少し調べてみる

なんでじゃ、と思ってこれまた調べてみると、プロジェクトごとに使うパッケージマネージャを指定するような使い方を想定しているようです。

そして、事前に使うパッケージマネージャを指定することもできるようです。
ということで、以下のコマンドで明示的にyarnを使うようにしてみます。

# 明示的にyarnを使う
corepack prepare --activate [email protected]

# yarnは入った・・・？
yarn
zsh: command not found: yarn

同じくコマンドがない、と怒られたのでいろいろ考えてみました。
ここで思い出したのが、rbenvではrehashというコマンドを使っていたこと。
gemや新しいバージョンのRubyをインストールしたときはとりあえずrehashしておけ、
という程度の認識でしたが、このような仕組みがasdfにもあるのでは、と思い調べてみました。

asdf reshim

調べてみると、ドンピシャな質問と回答が出てきました。
https://stackoverflow.com/questions/70082424/command-not-found-corepack-when-installing-yarn-on-node-v17-0-1

asdf reshim というコマンドでrbenv rehashのようなことができるとのこと。
https://asdf-vm.com/manage/core.html#reshim

上記によると、インストール時に~/.asdf/shimsへコマンドとして使えるようにファイルが自動的に生成されるが、それ以外ではファイルが生成されないのこと。今回の場合は、nodeインストール後に手動でcorepack enableやcorepack prepare --activate [email protected]を実行しているのでasdf的には存在を知らない。そこで、asdfに追加があったことを教えてあげて、ファイルを作ってもらう必要があったようだ。

# asdfにファイル生成をしてもらう
asdf reshim nodejs

# 確認
yarn -v
# => 3.2.2

ようやく使えるようになりました。
ただ、未確認ではありますが、asdf reshimの動きを見るとcorepack prepareは不要な気がします。
ということで、「環境構築の流れ」では省いてます。

おまけ: rbenv rehashについて改めて確認してみる

ここで、改めてrbenv rehashを調べてみました。
https://github.com/rbenv/rbenv#rbenv-rehash

御幣を恐れずにざっくり書けば、新しいgemやRubyをインストールした場合は「~/.rbenv/versions/*/bin/」にインストールされるが、PATHが通っているのは「~/.rbenv/shims」なのでそのままでは使うことはできません。
そこで、バージョン切り替えやgemのコマンドなどを追加する場合は新たに「~/.rbenv/shims」へコピーしてあげる必要があるわけです。そのコマンドがrbenv rehashのようです。

・・・とはいえ、いつの間にかrbenv installなどのタイミングで良しなにrbenv rehashが実行されるようになり明示的に実行する必要はなくなったようです。

ということで、asdfも正式版がリリースされる頃にはもしかしたら今回のようなごたごたはなくなるかもしれないなぁ・・・ということを思いながら、諸々調べる機会を与えてくれて感謝しつつ紆余曲折のメモを終わります。

まとめ

今回は、asdfを使ってNode.jsをインストールし、パッケージマネージャのYarnを使えるように環境構築をしました。
いつの間にかYarnのインストール方法が変わっていたり、asdfの仕組みに躓いたりしましたが、いろいろなことを調べたり知ることができたので満足です。

というわけで、今回はここまで。
おしまい

Windowsのnvmのnodeでfirebase-toolsを入れようとしたらUnexpected token '.' エラー

2022-07-17T11:29:34+09:00

npm install -g firebase-tools を実行してインストールしようとしたら下記のようなエラーが出た。

npm ERR! Unexpected token '.'

調べてみたらどうもWindowsのnvmのバージョン1.1.7以下を使っている場合に発生してしまうらしい。

ということで

nvm最新をインストール
Nodeの該当バージョンをアンインストール
Nodeの該当バージョンを再度インストール

で解決するとのこと。nvmだけでなくNodeも入れ直さないといけないっぽい。

参考）
https://github.com/firebase/firebase-tools/issues/4134

Tiddlywiki を Android で使う

2022-04-13T14:42:49+09:00

Tiddlywiki とはどういうものかというと、情報カードみたいにセルを取り出せるブログまたは、 wiki みたいな Zettelkasten てものです。

https://tiddlywiki.com/

html ファイル 1 つだけで完結しているものも出来上がるので、github pages でおいておくこともできます。

https://ja.m.wikipedia.org/wiki/TiddlyWiki

Tiddlywiki を android で termux アプリを使って node.js の web サーバーで使う場合について書きます。

ctrl キーが必要なので hacker's keyboard などの仮想キーボードアプリが必要です。

https://github.com/klausw/hackerskeyboard

まずはじめに node.js をインストールしておきます。

pkg （ termux のパッケージマネージャーのコマンド）でインスールします。

pkg install nodejs

npm （ node.js のパッケージマネージャーの npm コマンド）を使ってTiddlywiki をインストール。


u0_a185@localhost ~> npm install -g tiddlywiki

added 1 package, and audited 2 packages in 17s

found 0 vulnerabilities
npm notice
npm notice New minor version of npm available! 8.5.4 -> 8.6.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v8.6.0
npm notice Run npm install -g [email protected] to update!
npm notice

local host (127.0.0.1) に mywiki という名前で、tiddlywiki （ウィキ）を作ってみます。

u0_a185@localhost ~> tiddlywiki mywiki --init server
Copied edition 'server' to mywiki

local host ポート番号 8080 に web サーバーを起ち上げます。

u0_a185@localhost ~> tiddlywiki mywiki --server 8080
 syncer-server-filesystem: Dispatching 'save' task: $:/StoryList
Serving on http://127.0.0.1:8080
(press ctrl-C to exit)

ブラウザのアドレスバーに、127.0.0.1:8080 とタイプしてエンターします。
あとはブラウザ上で、操作します。

終わるときは node.js の webサーバーをストップさせます。

termux のターミナル上で ctrl キーと c で node.js の web サーバーを止めます。

plugin を追加するには、web サーバーを止めておいて、ターミナルから、作った mywiki ディレクトリにある tiddlywiki.info ファイルをテキストエディターで編集します。plugin 、は存在が確認できているものを tiddlywiki.info に書き足していくと、サーバーを起動してブラウザでアクセスすると反映されています。json 形式のファイルを編集したことがあれば、下のキャプチャした画像を見れば理解できるはずです。

markdown のプラグインを追加している様子。

https://youtu.be/KsXCTbRmAHI

GitHub ActionsでEACCES: permission deniedが出るとき

2022-02-21T21:08:44+09:00

GitHub Actionsでnpx prisma generateを実行するとEACCES: permission deniedというエラーが出て全然うまくいかない。

ためしに yarn prisma generate とすると動いた。npxだとユーザーかなにかが違う…？

colors.js, faker.js 等を使用しているか調べる簡易チェッカー

2022-01-11T23:52:59+09:00

先日ショッキングな commit が push されたというニュースを知りました。そこで念のため colors や faker の開発者が開発したパッケージを自分のプロジェクトが使用しているかを調べる簡易チェッカーを作ってみました。

経緯

やろうと思えばできてしまうのがオープンソース界隈のエコシステムの怖いところではあります。

詳細は上述の記事をご参照ください。

それよりも、目下気になるのは自分のプロジェクトでこれらの npmパッケージを使用していないかどうか。

https://gist.githubusercontent.com/azu/11b105a9e35dc9d5f07312c24a35c82b/raw/000a0c728ac1748b6fb3c80c8a0753fb1f6a57e8/marak-packages.md

colors や faker を開発した方がメンテナーになっているパッケージ一覧をazu氏が作ってくださったので、このリストを元にパッケージの使用を確認する簡易チェッカーを作ってみました。

成果物

GitHub - arm-band\/test-adramelek

コード (要点のみ)

const path          = require('path');
const request       = require('request');
const { spawnSync } = require('child_process');
const fs            = require('fs');
const marakOwnedUrl = 'https://gist.githubusercontent.com/azu/11b105a9e35dc9d5f07312c24a35c82b/raw/000a0c728ac1748b6fb3c80c8a0753fb1f6a57e8/marak-packages.md';

// 略

request.get({
    url: marakOwnedUrl,
}, function (error, response, body) {
    const mdStream = body.split("\n");
    const packageNamesArray = mdStream.filter((val) => {
        return val.length > 0 && !val.startsWith('http');
    });
    let cnt = {
        found: 0,
        notfound: 0,
    }
    let resultStr = `Project: ${projectPathStr}
`;
    for (let i = 0; i < packageNamesArray.length; i++) {
        console.log(`yarn why ${packageNamesArray[i]}`);
        resultStr += `Package "${packageNamesArray[i]}":  ${i + 1} / ${packageNamesArray.length}
> yarn why ${packageNamesArray[i]}
`;
        console.log(`package "${packageNamesArray[i]}":  ${i + 1} / ${packageNamesArray.length}`);
        const spawn = spawnSync(`yarn why ${packageNamesArray[i]} --cwd ${projectPathStr}`, { shell: true });
        console.log(spawn.stdout.toString());
        resultStr += `${spawn.stdout.toString()}
`;
        console.log(spawn.stderr.toString());
        resultStr += `${spawn.stderr.toString()}
`;
        spawn.stderr.toString().length > 0 ? cnt.notfound++ : cnt.found++;
    }
    const cntMsg = `
Found packages: ${cnt.found}
Not found packages: ${cnt.notfound}`;
    console.log(cntMsg);
    resultStr += cntMsg;
    try{
        fs.writeFileSync(path.join(path.join('.', 'dist'), `scan-result-${projectName}.log`), resultStr);
      }
      catch(e){
        console.log(e.message);
      }
});

先程の mdファイルをHTTPリクエストで取得し、パッケージ名の行のみ(1行の文字列が0(改行のみ)とhttp始まりを除外)処理します
パッケージ名分ループして、 child_process の spawn を使用し、 yarn why {パッケージ名} --cwd {プロジェクトのパス} コマンドを実行 (npm は今回は見ていません)
- コマンドライン引数でプロジェクトのパスを指定することで、該当プロジェクトのディレクトリで yarn why をしています
実行結果を console.log で表示しつつ、メモリに格納。全ての確認が終わるとテキストファイルにダンプします
- 標準出力エラー(パッケージが見付からなかった)と成功(パッケージが見付かった)をカウントして出力に付与しています
- 標準出力エラーを使うために spawn を使用

スピード重視でざっくり作りました。ひとまず自分の手元で動いて予期する動作になったので公開しました。

参考

きっかけ

📔 ECS Fargate のメトリクスを Prometheus Agent 使って AMP に送って Grafana で監視する

2021-12-19T01:01:44+09:00

はじめに

この記事は AWS Advent Calendar 2021 の 5 日目の記事です。

Fargate で Node.js アプリのメトリクスを Prometheus Agent をサイドカーコンテナとして動かして、Amazon Managed Service for Prometheus (AMP) に送信して Grafana で見られるようにしてみました。

ちなみに Promethus Agent はまだ実験的な機能なため、実務での利用は推奨しません。

本記事の環境構築には AWS CDK を利用しています。

動作環境

Node.js v16.13.0
AWS CDK 2.0.0 (build 4b6ce31)
Prometheus 2.32.1

環境構築

AWS CDK で環境構築する

CDK で構築作業を進めます。まずは下記コマンドで CDK プロジェクトを作成します。使用言語は TypeScript を選択します。

mkdir prometheus-agent-test && cd prometheus-agent-test
cdk init --language typescript

まず CDK でインフラ構築を進めていく前に、メトリクス収集テスト用の Node.js アプリを準備します。

ECS Fargate で動かす Node.js アプリを準備する

prom-client を利用して、Node.js のメトリクスが取得できるだけの Node.js アプリを準備します。prometheus-agent-test フォルダで下記コマンドを実行します。

mkdir metrics-app && cd metrics-app
npm init -y
npm install --save prom-client

次に metrics-app フォルダ内に index.js を作成して下記を編集します。

// metrics-app/index.js
"use strict";

const http = require("http");
const server = http.createServer();

const client = require("prom-client");
const register = new client.Registry();

// 5秒間隔でメトリクスを取得する
client.collectDefaultMetrics({ register, timeout: 5 * 1000 });

server.on("request", async function (req, res) {
  // /metrics にアクセスしたら、Prometheus のレポートを返す
  if (req.url === "/metrics") {
    res.setHeader("Content-Type", register.contentType);

    const metrics = await register.metrics();
    return res.end(metrics);
  } else {
    return res.writeHead(404, { "Content-Type": "text/plain" });
  }
});

server.listen(8080);

node index.js コマンドを実行して http://localhost:8080/metrics にアクセスしてみます。下記のように各種メトリクスが出力されている様子が確認できれば OK です。

Prometheus のレポートが正常に出力されている様子

今回は ECS 上で Node.js アプリを動作させるため、Dockerfile も作成します。

# metrics-app/Dockerfile
FROM public.ecr.aws/docker/library/node:16-alpine3.12 AS builder

EXPOSE 8080
WORKDIR /usr/src/app

COPY package*.json ./
RUN npm install --max-old-space-size=4096

COPY . .

CMD [ "node", "index.js" ]

上記 Dockerfile 作成後、再び動作検証のため下記コマンドを実行してから、http://localhost:8080/metrics にアクセスしてみます。

docker build -t prometheus-agent-test/metrics-app .
docker run -p 8080:8080 prometheus-agent-test/metrics-app:latest

先ほどと同様に http://localhost:8080/metrics アクセス時に各種メトリクスが出力されている様子を確認できれば OK です。

Node.js アプリを監視する Prometheus Agent を準備する

まずは Prometheus 関連ファイルを配置するためのフォルダを作成します。prometheus-agent-test フォルダ内で下記コマンドを実行します。

mkdir prometheus-agent && cd prometheus-agent

次に Prometheus の設定テンプレートファイルを作成します。テンプレートファイルは sed を利用して中身の __TASK_ID__ および __REMOTE_WRITE_URL__ を書き換えて利用します。

# prometheus-agent/prometheus.tmpl.yml
global:
  scrape_interval: 5s
  external_labels:
    monitor: "prometheus"

scrape_configs:
  - job_name: "prometheus-agent-test"
    static_configs:
      - targets: ["localhost:8080"]
        labels:
          # デフォルトの localhost:8080 がインスタンスとして利用されると、
          # メトリクスの判別がしづらくなるため ECS Task の ID を利用する
          instance: "__TASK_ID__"

remote_write:
  # AMP ワークスペース作成時に控えておいた、
  # `エンドポイント - リモート書き込み URL` を設定する箇所
  - url: "__REMOTE_WRITE_URL__"
    sigv4:
      region: ap-northeast-1
    queue_config:
      max_samples_per_send: 1000
      max_shards: 200
      capacity: 2500

設定ファイルの作成が完了したら、テンプレートファイルを利用して Prometheus の設定ファイルを作成し、Prometheus Agent を起動させるためのシェルスクリプトを作成します。

# prometheus-agent/docker-entrypoint.sh
#!/bin/sh

while [ -z "$taskId" ]
do
  # ECS Fargate で起動したタスク ID を取得する
  taskId=$(curl --silent ${ECS_CONTAINER_METADATA_URI}/task | jq -r '.TaskARN | split("/") | .[-1]')

  echo "waiting..."
  sleep 1
done

echo "taskId: ${taskId}"
echo "remoteWriteUrl: ${REMOTE_WRITE_URL}"

# タスク ID `taskId` および、環境変数 `REMOTE_WRITE_URL` で、
# Prometheus のテンプレートファイル `prometheus.tmpl.yml` の内容を書き換え、
# その結果を `/etc/prometheus/prometheus.yml` に出力する
cat /etc/prometheus/prometheus.tmpl.yml | \
    sed "s/__TASK_ID__/${taskId}/g" | \
    sed "s>__REMOTE_WRITE_URL__>${REMOTE_WRITE_URL}>g" > /etc/prometheus/prometheus.yml

# --enable-feature=agent で Prometheus を Agent モードで起動する
# Prometheus のコンフィグファイルには上記で出力した `/etc/prometheus/prometheus.yml` を利用する
/usr/local/bin/prometheus \
    --enable-feature=agent \
    --config.file=/etc/prometheus/prometheus.yml \
    --web.console.libraries=/etc/prometheus/console_libraries \
    --web.console.templates=/etc/prometheus/consoles

これで Prometheus Agent 起動のための準備は整ったため、最後に Dockerfile を準備します。ちなみに Prometheus Agent は v2.32.0 以降で利用可能です。本記事では v2.32.1 を利用します。

# prometheus-agent/Dockerfile
FROM --platform=arm64 alpine:3.15

ADD prometheus.tmpl.yml /etc/prometheus/

RUN apk add --update --no-cache jq sed curl

# ARM64 で動作する Prometheus v2.32.1 を curl でダウンロード展開する
RUN curl -sL -O https://github.com/prometheus/prometheus/releases/download/v2.32.1/prometheus-2.32.1.linux-arm64.tar.gz
RUN tar -zxvf prometheus-2.32.1.linux-arm64.tar.gz && rm prometheus-2.32.1.linux-arm64.tar.gz

# `prometheus` コマンドを `/usr/local/bin/prometheus` に移動する
RUN mv prometheus-2.32.1.linux-arm64/prometheus /usr/local/bin/prometheus

COPY ./docker-entrypoint.sh /
RUN chmod +x /docker-entrypoint.sh
CMD ["/docker-entrypoint.sh"]

ここまでで CDK でインフラ整備を進めていくための下準備は完了です。

ECS Fargate 上で Node.js アプリおよび Prometheus Agent を動作させる

あとは CDK で ECS Fargate 上で Node.js アプリおよび Prometheus Agent、Grafana を動作させるための環境を整備していきます。

lib/prometheus-agent-test-stack.ts の内容を書き換えます。

// lib/prometheus-agent-test-stack.ts
import { Construct } from "constructs";
import {
  Stack,
  StackProps,
  aws_ecs as ecs,
  aws_logs as logs,
  aws_aps as aps,
  aws_ecs_patterns as ecs_patterns,
  aws_iam as iam,
  aws_elasticloadbalancingv2 as elbv2,
  Duration,
  CfnOutput,
} from "aws-cdk-lib";

export class PrometheusAgentTestStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    // Node.js アプリに ecs_patterns.ApplicationLoadBalancedFargateService を利用して ALB 経由でアクセス可能にする
    const projectName = "prometheus-agent-test";
    const fargateService =
      new ecs_patterns.ApplicationLoadBalancedFargateService(
        this,
        `${projectName}-fargate-service`,
        {
          serviceName: `${projectName}-fargate-service`,
          cpu: 256,
          desiredCount: 3,
          listenerPort: 80,
          taskImageOptions: {
            family: `${projectName}-taskdef`,
            image: ecs.ContainerImage.fromAsset("metrics-app"),
            containerPort: 8080,
            logDriver: ecs.LogDrivers.awsLogs({
              streamPrefix: `/${projectName}/metrics-app`,
              logRetention: logs.RetentionDays.ONE_DAY,
            }),
          },
          cluster: new ecs.Cluster(this, `${projectName}-cluster`, {
            clusterName: `${projectName}-cluster`,
          }),
          memoryLimitMiB: 512,
        }
      );
    fargateService.targetGroup.configureHealthCheck({
      path: "/metrics",
      timeout: Duration.seconds(8),
      interval: Duration.seconds(10),
      healthyThresholdCount: 2,
      unhealthyThresholdCount: 4,
      healthyHttpCodes: "200",
    });

    // 本質ではないが、Gravition2 で動作させたいために RuntimePlatform のプロパティを上書きしている
    const fargateServiceTaskdef = fargateService.taskDefinition.node
      .defaultChild as ecs.CfnTaskDefinition;
    fargateServiceTaskdef.addPropertyOverride("RuntimePlatform", {
      CpuArchitecture: "ARM64",
      OperatingSystemFamily: "LINUX",
    });

    // AMP への書き込み権限を付与する
    fargateService.taskDefinition.taskRole.addManagedPolicy(
      iam.ManagedPolicy.fromAwsManagedPolicyName(
        "AmazonPrometheusRemoteWriteAccess"
      )
    );

    // (2021/12/18) Amazon Managed Service for Prometheus のワークスペースを作成して、Prometheus の remote-write URL を取得する
    const apsWorkspace = new aps.CfnWorkspace(
      this,
      `${projectName}-prom-workspace`,
      {
        alias: `${projectName}-prom-workspace`,
      }
    );
    const apsWorkspaceRemoteUrl = `${apsWorkspace.attrPrometheusEndpoint}api/v1/remote_write`;

    // (2021/12/18) 本記事で頻出する "エンドポイント - リモート書き込み URL" をコンソールに出力する
    new CfnOutput(this, "prom-remote-write-url", {
      value: apsWorkspaceRemoteUrl,
      description: "Prometheus Workspace の remote-write URL",
      exportName: "PromRemoteWriteURL",
    });

    // AMP へメトリクス情報を送信するための Prometheus Agent コンテナを追加する
    const containerName = `${projectName}-prometheus-agent`;
    fargateService.taskDefinition.addContainer(containerName, {
      containerName,
      image: ecs.ContainerImage.fromAsset("prometheus-agent"),
      memoryReservationMiB: 128,
      environment: {
        // (2021/12/18) CDK 経由で作成した Prometheus の remote-write URL を設定する
        REMOTE_WRITE_URL: apsWorkspaceRemoteUrl,
      },
      logging: new ecs.AwsLogDriver({
        streamPrefix: `/${projectName}/prometheus-agent`,
        logRetention: logs.RetentionDays.ONE_DAY,
      }),
    });

    // Grafana のタスク定義を作成する
    const grafanaDashboardTaskDefinition = new ecs.FargateTaskDefinition(
      this,
      `${projectName}-grafana-taskdef`,
      {
        family: `${projectName}-grafana-taskdef`,
      }
    );
    // Grafana のタスクが Prometheus Query を叩けるように権限付与する
    grafanaDashboardTaskDefinition.taskRole.addManagedPolicy(
      iam.ManagedPolicy.fromAwsManagedPolicyName("AmazonPrometheusQueryAccess")
    );

    // Grafana のコンテナを追加する。パスプレフィクスには dashboard を設定する
    const grafanaDashboardContainerName = `${projectName}-grafana-dashboard`;
    grafanaDashboardTaskDefinition.addContainer(grafanaDashboardContainerName, {
      containerName: grafanaDashboardContainerName,
      image: ecs.ContainerImage.fromRegistry("public.ecr.aws/ubuntu/grafana"),
      environment: {
        AWS_SDK_LOAD_CONFIG: "true",
        GF_AUTH_SIGV4_AUTH_ENABLED: "true",
        GF_SERVER_SERVE_FROM_SUB_PATH: "true",
        GF_SERVER_ROOT_URL: "%(protocol)s://%(domain)s/dashboard",
      },
      portMappings: [{ containerPort: 3000 }],
      memoryLimitMiB: 512,
      logging: new ecs.AwsLogDriver({
        streamPrefix: `/${projectName}/grafana-dashboard`,
        logRetention: logs.RetentionDays.ONE_DAY,
      }),
    });

    const grafanaDashboardServiceName = `${projectName}-grafana-dashboard-service`;
    const grafanaDashboardService = new ecs.FargateService(
      this,
      grafanaDashboardServiceName,
      {
        serviceName: grafanaDashboardServiceName,
        cluster: fargateService.cluster,
        taskDefinition: grafanaDashboardTaskDefinition,
        desiredCount: 1,
      }
    );

    // Grafana のタスクを ALB のターゲットグループに紐づける
    fargateService.listener.addTargets(
      `${projectName}-grafana-dashboard-target`,
      {
        priority: 1,
        conditions: [elbv2.ListenerCondition.pathPatterns(["/dashboard/*"])],
        healthCheck: {
          path: "/dashboard/login",
          interval: Duration.seconds(10),
          timeout: Duration.seconds(8),
          healthyThresholdCount: 2,
          unhealthyThresholdCount: 3,
          healthyHttpCodes: "200",
        },
        port: 3000,
        protocol: elbv2.ApplicationProtocol.HTTP,
        targets: [grafanaDashboardService],
      }
    );
  }
}

その後、cdk deploy でインフラを構築します。

CDK によるインフラ構築が正常に実行された時の様子

デプロイが正常に完了したのを確認したら、Outputs に出力されている PrometheusAgentTestStack.prometheusagenttestfargateserviceServiceURL<識別子> の URL 末尾に /metrics を付与してアクセスしてみます。 出力されている URL のフォーマットは http://<識別子>.ap-northeast-1.elb.amazonaws.com になります。

つまり、http://<識別子>.ap-northeast-1.elb.amazonaws.com/metrics にアクセスします。

ALB 経由で Node.js アプリにアクセス可能なことを確認する

また、Outputs に出力されている PrometheusAgentTestStack.promremotewriteurl は後に利用する エンドポイント - リモート書き込み URL で使用するので控えておきます。

ここまでで AWS CDK でのインフラ構築作業は完了しました。最後に Grafana で AMP のメトリクスを可視化するための作業を進めていきます。

Grafana で Prometheus (AMP) のメトリクスを可視化する

先ほどの /metrics パスへのアクセス同様、Outputs に出力されている URL の末尾に /dashboard/login を付与してアクセスします。Grafana の初期ユーザおよびパスワードは admin となります。

つまり、http://<識別子>.ap-northeast-1.elb.amazonaws.com/dashboard/login にアクセスしてみます。

ログイン情報が正しければ、新しいパスワードを設定する画面に遷移するので新たなパスワードを入力してログインを終えます。ログイン後は、Prometheus (AMP) をデータソースとして追加するために下記の操作を行います。

Data sources をクリックする" />
1. 歯車アイコンをクリックして Data sources をクリックする

Add data source ボタンをクリックする" />
2. Add data source ボタンをクリックする

3. データソースとして Prometheus を選択する

4. Prometheus をデータソースとして追加する

Prometheus (AMP) に送信したメトリクスを Grafana で可視化するための準備が整ったので、実際に Grafana のダッシュボードでメトリクスを可視化してみます。手っ取り早くメトリクスを可視化するため、ダッシュボードには NodeJS Application Dashboard を利用します。

Import をクリックする" />
1. + アイコンをクリックして、Import をクリックする

NodeJS Application Dashboard の ID を入力して Load ボタンをクリックする" />
2. NodeJS Application Dashboard の ID を入力して Load ボタンをクリックする

NodeJS Application Dashboard のインポートを完了する" />
3. 必要な情報を入力して NodeJS Application Dashboard のインポートを完了する

4. ダッシュボードから Node.js アプリのメトリクスが確認できる

ここまでの手順でメトリクスの可視化は完了しましたが、負荷に応じて実際にメトリクスが変化する様子も確認してみます。Vegeta を利用して、実際に負荷をかけてみます。下記コマンドを実行します。

echo 'GET http://<識別子>.ap-northeast-1.elb.amazonaws.com/metrics' | vegeta attack -duration=5s | vegeta report

その後、再び Grafana のダッシュボードを見にいきます。負荷をかけた時間帯のみグラフに変化があることを確認できるはずです。

ダッシュボードの CPU 使用率のグラフに変化があったことを確認できる

おわりに

今回は ECS Fargate のメトリクスを Prometheus Agent で Amazon Managed Service for Prometheus (AMP) に送信し、それを Grafana で可視化する方法について紹介しました。

ECS のサービスでタスクを実行する場合はサービスディスカバリの利用が可能なため、Prometheus のサービスディスカバリの設定を行うことで、単一の Prometheus で全てのコンテナのメトリクスを扱うことも可能です。

また Node.js アプリを作成する際に利用した prom-client でカスタムメトリクスを作成することで、監視したい項目を自由に増やすことも可能です。

本記事が ECS Fargate を監視する際の検討材料の 1 つとなれたら幸いです。

参考リンク

package.json の情報をスクリプト内で参照したい

2021-09-08T23:30:59+09:00

package.json の情報をスクリプト内で参照したくなったのでその方法をメモ。

方法

const packageJson = require('./package.json');

console.log(packageJson.version);
// 0.0.1
console.log(packageJson.dependencies);
// { bootstrap: '^5.1.0' }

普通に require で読み込めるようです。

const packageJson = require('./package.json');

console.log(packageJson.version);
// 0.0.1
console.log(packageJson.devDependencies['browser-sync']);
// ^2.27.5

パッケージ名にハイフンがある場合はオブジェクトのキー名を指定する形式で使用パッケージのバージョン情報が取得できますね。

思ったよりも簡単にできることが確認できました。

ちなみに……

> node -v
v16.3.0
> npm -v
7.15.1

実行環境はとあるプロジェクトでこんな感じでした。最新に上げないといけませんがそれはそれとして。

参考

package.jsonのversionをコマンド(ワンライナー)で取り出したい - Qiita
package.jsonの各種要素を読み込みたい！ - DEV Community
scripts | npm Docs
- process.env.npm_package_XXXXXXXXXX の形は手元の環境で試したところ undefined になってしまいました……

npm でパッケージを公開する

2021-09-07T23:46:08+09:00

一度は試してみたいと思っていた npmパッケージの公開をやってみることにします。

パッケージの準備

今回はテストのため、事前に作ってあったconsole.log で画像を表示するプログラムで試すことにしてみます。

ちなみにパッケージは以下のものがあるようなイメージで。

package.json
- name
- description
- version
- main
- author
- license
- 辺りが記述されていること
.gitignore
(.npmignore)
LICENSE
テストコード
CI設定

リポジトリ

GitHub - arm-band/console-cafebabe: npmパッケージのテスト。 console.log で画像を出力します。

一揃いを準備。ついでに Github Actions でバッジを付けておきます。

npm アカウントの作成

続いて npm にアカウントを作成します。

ユーザ名、パスワード、メールアドレスを入力。ちなみにメールアドレスはパッケージのメタ情報に含まれて第三者に公開される可能性がある、との注意書きがあるので念のため専用のメールアカウントを用意しておきます。

ログインするとメールでの認証を求められるので先ほど入力したメールアドレスに届いている認証のボタンを押しておきます。

認証完了。

npmパッケージの公開

npmアカウントの作成が完了したらいよいよパッケージの公開作業です。

パッケージのプロジェクトのルートディレクトリでターミナルを開き、 npm login で npm にログインします。

> npm login
npm notice Log in on https://registry.npmjs.org/
Username: YOURNPMUSERNAME
Password:
Email: (this IS public) [email protected]
Logged in as YOURNPMUSERNAME on https://registry.npmjs.org/.

OK。次に念のためパッケージとして公開されるファイルを確認しておきます。

> npm pack
npm notice 
npm notice 📦  [email protected]
npm notice === Tarball Contents ===
npm notice 125B  __tests__/main.test.js
npm notice 401B  .github/workflows/ci.yml
npm notice 1.0kB LICENSE
npm notice 44B   bin/cli.js
npm notice 36B   bin/postinstall.js
npm notice 82B   index.js
npm notice 57B   jest.config.js
npm notice 417B  package.json
npm notice 277B  readme.md
npm notice 6.9kB src/main.js
npm notice === Tarball Details === 
npm notice name:          console-cafebabe
npm notice version:       0.0.1
npm notice filename:      console-cafebabe-0.0.1.tgz
npm notice package size:  6.7 kB
npm notice unpacked size: 9.4 kB
npm notice shasum:        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
npm notice integrity:     sha512-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
npm notice total files:   10
npm notice
console-cafebabe-0.0.1.tgz

npm pack するとtgz形式でパッケージの圧縮ファイルが生成されます。 Tarball Contents の中身や実際に展開して中身を確認し、公開したくないファイルが混ざってないか最後のチェックを行います。問題なければ公開へ。

> npm publish
npm notice 
npm notice 📦  [email protected]
npm notice === Tarball Contents ===
npm notice 125B  __tests__/main.test.js
npm notice 401B  .github/workflows/ci.yml
npm notice 1.0kB LICENSE
npm notice 44B   bin/cli.js
npm notice 36B   bin/postinstall.js
npm notice 82B   index.js
npm notice 57B   jest.config.js
npm notice 417B  package.json
npm notice 277B  readme.md
npm notice 6.9kB src/main.js
npm notice === Tarball Details ===
npm notice name:          console-cafebabe
npm notice version:       0.0.1
npm notice filename:      console-cafebabe-0.0.1.tgz
npm notice package size:  6.7 kB
npm notice unpacked size: 9.4 kB
npm notice shasum:        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
npm notice integrity:     sha512-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
npm notice total files:   10
npm notice
+ [email protected]

npm publish で公開します。わりとあっという間に終わります。

npm 上で検索すると公開したパッケージが見付かります。きちんと公開されていますね！

インストールテスト

今度はインストールしてみましょう。 package.json で以下のように自分のパッケージを dependencies に追加します。

    "dependencies": {
        "console-cafebabe": "0.0.1"
    },

npm i -D または yarn 。

node_modules の中に入ってきましたね。これだけでもちょっと感動。

import consoleCafebabe from 'console-cafebabe';

consoleCafebabe.coffee();

Webpack前提のプロジェクトのエントリポイントのJSに import して、想定通りの使い方としてメソッドを呼び出してみます。

作った通り、 console.log に画像や装飾された文字列が表示されました。成功です。

ログアウト

> npm logout
>

パッケージ公開後は npm logout でターミナル上でもログアウトしておくと事故の確率が減らせそうなのでログアウトしておきます。

これで一通りの流れは押さえることができたと思います。

参考

gulp-imagemin で Error [ERR_REQUIRE_ESM]: Must use import to load ES Module と怒られる

2021-08-17T23:17:25+09:00

経緯

ある日、 package gardening をして Gulp を走らせたら

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module

と怒られてしまいました。

$ gulp
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: PATH\TO\PROJECT\DIRECTORY\node_modules\gulp-imagemin\index.js
require() of ES modules is not supported.
require() of PATH\TO\PROJECT\DIRECTORY\node_modules\gulp-imagemin\index.js from PATH\TO\PROJECT\DIRECTORY\gulp\tasks\imagemin.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from PATH\TO\PROJECT\DIRECTORY\node_modules\gulp-imagemin\package.json.

今回は gulp-imagemin のスクリプトの中に起因するようなので、そちらに手を入れるのは避けたいところです。

さて、どうしたものか。

結論

結論から先にいうと、 gulp-imagemin をダウングレードすることで回避するしかなさそうです。

今回は 8.0.0 から既存の 7.1.0 にダウングレードします。

調査

"type": "module"

Node.js の ESModules

検索すると、 package.json にパラメータを追記する方法が出てきます。

{
    "engines": {
        "node": ">=16.0.0",
        "npm": ">=6.14.9"
    },
    "engineStrict": true,
    "prettier": {},
    "type": "module" // 追記
}

"type": "module" を追記する方法です。

しかし、この方法を採用する場合、既存の Gulpタスク全てを CommonJS (require) から ES Modules (import) に書き換える必要があります。

それはそれで既存スクリプトの書き換えが大変なことになってしまうので、この方法は今回は不採用。

公式リポジトリを覗く

そこで公式リポジトリを覗いてみます。

早速同じ内容の Issues が散見されます。そして回答では「リリースノートを見よ」とのこと。

Releases · sindresorhus/gulp-imagemin · GitHub

This package is now pure ESM. Please read this.

Releases · sindresorhus/gulp-imagemin · GitHub

最初からここを見ましょう、という話ではあるのですが。

Pure ESM package · GitHub

ご覧の通り、「8.0.0 からは ES Modules のパッケージになっていますよー」というアナウンス。

したがって、先の結論の通り CommonJS を使用したければダウングレードせよ、ということになります。是非もなし。

参考

Node.js のバージョン管理として Volta を使う

2021-08-09T17:46:21+09:00

Nodist から脱却する方法第二弾。

経緯

Docker で Node.js のバージョン切替環境を構築するで一度 Docker 環境上に Node.js 環境を作りましたが、メモリ領域の不足で遅かったり Browsersync との連動が面倒だったりしたので、やはり一枚レイヤーを挟まずホスト側でストレートに構築する方法も模索すべきか……と思い至ったので Volta を試すことにしました。

Nodist のアンインストール

今回はPCに直接インストールする形なのでモロに Nodist のバッティングします。そこで、まずは Nodist をアンインストールします。

1. Nodist のアンインストール

まずはアンインストール。コンパネからでも Nodist のインストールフォルダにある uninstall.exe を実行するのでもどちらでも。

2. フォルダの削除

アンインストールしても Nodist のフォルダやら残骸がインストールフォルダ (デフォルトならば C:\Program Files (x86)\Nodist\) に残るので、これを強制削除。

3. .npmrc の削除

使用ユーザのフォルダ直下に .npmrc (C:\Users\\.npmrc) が残るのでこれを削除……と言いたいところですが、私の場合は存在していませんでした。

そのため、ここはパス。

4. npm-cache の削除

使用ユーザのAppData\Roaming の下に npm-cache (C:\Users\\AppData\Roaming\npm-cache) が残るのでこれを削除。

5. 環境変数の確認

環境変数に Nodist の Node.js へのパスが残っている場合はこれを削除……と言いたいところですが、私の場合は存在していませんでした。

そのため、ここもパス。

Volta のインストール

Nodist を削除したら、 Volta をインストールします。

Releases · volta-cli/volta · GitHub

記事執筆時は 1.0.4 が最新でした。この msi をダウンロード。後は実行してインストール。

>volta -v
1.0.4

入りました。

>volta install [email protected]
success: installed and set [email protected] (with [email protected]) as default            9

>node -v
v16.3.0

>npm -v
7.15.1

続いて適当なバージョンの Node.js をインストールします。 npm も入りました。良い感じですね。

>volta install yarn
success: installed and set [email protected] as default                             0

>yarn -v
1.22.11

yarn も入れます。

とあるプロジェクトで、 Node.js のバージョンを14系で固定してみます。

> volta pin node@14
success: pinned [email protected] (with [email protected]) in package.json

OK.

    "volta": {
        "node": "14.17.4"
    }

package.json に Volta 使用時の Node.js のバージョンが追記されました。これでプロジェクトごとにバージョンを切り替えられるのは良いですね。

参考

Nodist アンインストール

2020 年ではもう使えない Nodist はアンインストールする (Windows)

Volta

Docker で Node.js のバージョン切替環境を構築する

2021-07-05T23:53:53+09:00

経緯

Windows環境では長らく Nodist を使ってきましたが、流石にそろそろ見切りを付けて安定的に Node.js を使用できる環境を構築したいと考えました。

理由としては以下の2点。

そもそも Nodist のバージョンが 0.9.1 (< 1.0.0) であること
0.9.1 のリリースが2019/3/30で、2年以上も更新がされていないこと

正直、2020 年ではもう使えない Nodist はアンインストールする (Windows)に全て書かれていることなので改めて書く必要はないかもしれません。

個人的には npm の切替時にエラーになってしまって切り替えられないなどの不具合が発生し始めたので、先述したようにそろそろ限界かな、と感じるようになりました。

そこで次の環境について考えたとき、やはり自PCの環境を汚さずに済むので Docker で構築することにしました。

構成

GitHub - arm-band/docker_sink_vertex: A collection of settings for running Node.js on Docker.

ディレクトリ構造

PROJECT_ROOT/
    │
    ├ .env
    ├ .gitignore
    ├ docker-compose.yml
    └ readme.md

今回は Docker公式イメージの Node.js を使うので、構成はいたってシンプルです。

.env

NODE_VERSION=16.3.0
PROJECT_ROOT_DIRECTORY=../workspace/

Docker Compose の前に .env のサンプルを。指定しているのは Node.js のイメージのバージョン指定とマウントするボリュームのパスです。

今回はそもそもバージョン切替可能な Node.js の環境を構築することが主眼なので、バージョン指定をパラメータで指定できるようにしておきます。

それから、 Node.js 環境で実行したいプロジェクトがあるはずなので、そのプロジェクトのディレクトリをコンテナ内にマウントさせるためにパス指定を記述しておきます。

docker-compose.yml

version: '3.8'
services:
    vertex:
      image: "node:$NODE_VERSION"
      user: "node"
      volumes:
        # project root
        - $PROJECT_ROOT_DIRECTORY:/home/node/app
      tty: true
      ports:
        - "3000:3000"
        - "3001:3001"

以上を踏まえて Docker Compose の yml 。

.env で説明した通り、 Node.js のイメージ指定とボリュームマウントの指定があります。

地味にポイントなのは ports 。今回は Browsersync を使った Gulpタスクを走らせようとしているのですが、ブラウザはホスト側にしかないため、ホストからコンテナ内の Browsersync の API を参照できるようにポートを指定しておきます。

これで試験してみます。

試験

上述の docker-compose.yml を作る途中で ports 指定をせず、何もカスタマイズしていない Gulp を走らせました。すると、以下のようなエラーが発生しました。

Couldn't open browser (if you are using BrowserSync in a headless environment, you might want to set the open option to false)

上述した通りブラウザはホスト側にしかなく、一方で Browsersync 含む Gulpタスクはコンテナ内で動いているので、当然と言えば当然ですよね。

これで ports 指定を加えました。

また、 Browsersync 側の設定も変更を加えます。

browserSync.init({
    server: {
        baseDir: './dist/'
    },
//    open: 'external',
    open: false,           // ブラウザオープンをしない
    https: true
});

openオプションを false にすることで、ブラウザを自動的に起動しないようにしました。これをしておかないと上述のエラーが発生してしまうので。

代わりに手動でブラウザを開く必要がありますが、已む無し。 https://localhost:3000/ できちんと見られるので良しとします。

試験2

追試験を実施している最中に、一部の環境で gulp.watch による自動ビルドが2回に1回しか走らない現象に遭遇しました。

Node.js のバージョンを切り替えてもダメで、しかも ejsファイルはOKですが scssファイルや ymlファイルはダメなど、条件がいまいちよく分かりません。

検索してみるとオプションで { usePolling: true } を指定すると直ったというのを見かけたので Gulpタスクに書き足してみました。

すると、現象が収まりました……ということは、ファイルをウォッチするタイミングか何かが上手くいっていないということ？

とりあえず動いたので良しとします。

試験3

試験2の途中で Node.js のバージョンを切り替えたらそもそも yarn がエラーでコケるなど副作用が発生したのでgulp-sass を Node.js v16 環境に合わせて調整するに書いたように諸々対処しました。

これでようやく想定している Gulpタスク一式が使えるようになりました。

参考

きっかけ
- 2020 年ではもう使えない Nodist はアンインストールする (Windows)
Couldn't open browser (if you are using BrowserSync in a headless environment, you might want to set the open option to false) のエラー
- javascript - Browsersync within a Docker container - Stack Overflow
- Laravel5.5、MixのBrowserSync
gulp.watch が動かない
- 【開発環境】gulpのwatchが動かない · Issue #54 · AyumuNekozuki/niconico-darkmode · GitHub

gulp-sass を Node.js v16 環境に合わせて調整する

2021-07-05T20:32:23+09:00

Node.js の 16系を試そうとしたら gulp-sass, node-sass 周りでエラーが発生したので対処をまとめておきます。

経緯

まず前提として

Dart Sass で / を使った徐算が非推奨となった (代わりに math.div を使えとのこと)
- 参考: Dart Sass で DEPRECATION WARNING: Using / for division is deprecated and will be removed in Dart Sass 2.0.0. の警告が表示される - Ewig Leere(Lab2)
上述現象を回避するため、 sass のバージョンを 1.32.12 で固定していた

という事情があります。

現象

この状態で Node.js のバージョンを 16系に切り替えて yarn 。

error /home/node/app/node_modules/node-sass: Command failed.
Exit code: 1
Command: node scripts/build.js
Arguments:
Directory: /home/node/app/node_modules/node-sass
Output:
Building: /usr/local/bin/node /home/node/app/node_modules/node-gyp/bin/node-gyp.js rebuild --verbose --libsass_ext= --libsass_cflags= --libsass_ldflags= --libsass_library=

# 略

In file included from /home/node/.node-gyp/16.3.0/include/node/v8.h:30,
                 from /home/node/.node-gyp/16.3.0/include/node/node.h:63,
                 from ../../nan/nan.h:56,
                 from ../src/binding.cpp:1:
/home/node/.node-gyp/16.3.0/include/node/v8-internal.h: In function 'void v8::internal::PerformCastCheck(T*)':
/home/node/.node-gyp/16.3.0/include/node/v8-internal.h:452:38: error: 'remove_cv_t' is not a member of 'std'
             !std::is_same>::value>::Perform(data);
                                      ^~~~~~~~~
/home/node/.node-gyp/16.3.0/include/node/v8-internal.h:452:38: note: suggested alternative: 'remove_cv'
             !std::is_same>::value>::Perform(data);
                                      ^~~~~~~
                                      remove_cv
/home/node/.node-gyp/16.3.0/include/node/v8-internal.h:452:38: error: 'remove_cv_t' is not a member of 'std'
/home/node/.node-gyp/16.3.0/include/node/v8-internal.h:452:38: note: suggested alternative: 'remove_cv'
             !std::is_same>::value>::Perform(data);
                                      ^~~~~~~
                                      remove_cv
/home/node/.node-gyp/16.3.0/include/node/v8-internal.h:452:50: error: template argument 2 is invalid
             !std::is_same>::value>::Perform(data);
                                                  ^
/home/node/.node-gyp/16.3.0/include/node/v8-internal.h:452:63: error: '::Perform' has not been declared
             !std::is_same>::value>::Perform(data);
                                                               ^~~
/home/node/.node-gyp/16.3.0/include/node/v8-internal.h:452:63: note: suggested alternative: 'herror'
             !std::is_same>::value>::Perform(data);
                                                               ^~~
                                                               herror
../src/binding.cpp: In function 'Nan::NAN_METHOD_RETURN_TYPE render(Nan::NAN_METHOD_ARGS_TYPE)':
../src/binding.cpp:284:98: warning: cast between incompatible function types from 'void (*)(uv_work_t*)' {aka 'void (*)(uv_work_s*)'} to 'uv_after_work_cb' {aka 'void (*)(uv_work_s*, int)'} [-Wcast-function-type]
     int status = uv_queue_work(uv_default_loop(), &ctx_w->request, compile_it, (uv_after_work_cb)MakeCallback);
                                                                                                  ^~~~~~~~
../src/binding.cpp: In function 'Nan::NAN_METHOD_RETURN_TYPE render_file(Nan::NAN_METHOD_ARGS_TYPE)':
../src/binding.cpp:320:98: warning: cast between incompatible function types from 'void (*)(uv_work_t*)' {aka 'void (*)(uv_work_s*)'} to 'uv_after_work_cb' {aka 'void (*)(uv_work_s*, int)'} [-Wcast-function-type]
     int status = uv_queue_work(uv_default_loop(), &ctx_w->request, compile_it, (uv_after_work_cb)MakeCallback);
                                                                                                  ^~~~~~~~
In file included from ../../nan/nan.h:56,
                 from ../src/binding.cpp:1:
../src/binding.cpp: At global scope:
/home/node/.node-gyp/16.3.0/include/node/node.h:806:43: warning: cast between incompatible function types from 'void (*)(Nan::ADDON_REGISTER_FUNCTION_ARGS_TYPE)' {aka 'void (*)(v8::Local)'} to 'node::addon_register_func' {aka 'void (*)(v8::Local, v8::Local, void*)'} [-Wcast-function-type]
       (node::addon_register_func) (regfunc),                          \
                                           ^
/home/node/.node-gyp/16.3.0/include/node/node.h:840:3: note: in expansion of macro 'NODE_MODULE_X'
   NODE_MODULE_X(modname, regfunc, NULL, 0)  // NOLINT (readability/null_usage)
   ^~~~~~~~~
../src/binding.cpp:358:1: note: in expansion of macro 'NODE_MODULE'
 NODE_MODULE(binding, RegisterModule);
 ^~~~~~~~~
make: *** [binding.target.mk:133: Release/obj.target/binding/src/binding.o] Error 1
make: Leaving directory '/home/node/app/node_modules/node-sass/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/node/app/node_modules/node-gyp/lib/build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (node:events:394:28)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)
gyp ERR! System Linux 5.10.25-linuxkit
gyp ERR! command "/usr/local/bin/node" "/home/node/app/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="
gyp ERR! cwd /home/node/app/node_modules/node-sass
gyp ERR! node -v v16.3.0

……滅茶苦茶怒られました (Docker内のLinux環境)。

ちなみに Windows環境だと yarn 時にはエラーにはなりませんが、 Gulpタスクを走らせた際に同様のエラーメッセージが表示されます。

対処1 (sass, gulp-sass のバージョンを上げる)

そこでまずは sass のバージョンを上げます。

ちなみに、 1.35.0以降では quietDeps: true のフラグを追加することで、冒頭の警告を非表示にできるようになったとのことなので、そもそもの問題は回避できるはずです。

    "devDependencies": {
        // 略
        "gulp-sass": "^4.1.0",
        "sass": "1.35.1",             // 1.32.12 からアップデート
        "fibers": "^5.0.0",
        "gulp-autoprefixer": "^7.0.1",
        // 略
    }

これで yarn してみましたが、ダメ。

ふと gulp-sass を見てみると、いつの間にか 5.0.0 がリリースされているではありませんか。

    "devDependencies": {
        // 略
        "gulp-sass": "^5.0.0",        // 4.1.0 からアップデート
        "sass": "1.35.1",             // 1.32.12 からアップデート
        "fibers": "^5.0.0",
        "gulp-autoprefixer": "^7.0.1",
        // 略
    }

そこで、 gulp-sass も上げます。これで yarn すると正常に完了。

安心して Gulpタスクを走らせると……

../src/coroutine.cc:134: void* find_thread_id_key(void*): Assertion `thread_id_key != 0x7777' failed.

…別のエラーで怒られました。

対処2 (fibers を削除)

node.js - (thread_id_key != 0x7777), function find_thread_id_key, file ../src/coroutine.cc, line 134 - Stack Overflow

検索すると上述のエラーは fibers が Node.js 16系に対応していないために発生している模様。

そのため、 fibers を削除します。

    "devDependencies": {
        // 略
        "gulp-sass": "^5.0.0",        // 4.1.0 からアップデート
        "sass": "1.35.1",             // 1.32.12 からアップデート
        "gulp-autoprefixer": "^7.0.1",
        // 略
    }

併せてタスクも書き換えます。

const sass          = require('gulp-sass');
sass.compiler       = require('sass');
//const Fiber         = require('fibers');

// 略

            .pipe(sass({
//                fiber: Fiber,
                outputStyle: 'compressed',
                quietDeps: true            // 警告回避のために追加
            }).on('error', sass.logError))

// 略

fibers 関係を削除。

これで yarn し直してタスクを再実行。

Error in plugin "gulp-sass"
Message:

gulp-sass 5 does not have a default Sass compiler; please set one yourself.
Both the `sass` and `node-sass` packages are permitted.
For example, in your gulpfile:

  var sass = require('gulp-sass')(require('sass'));

……別のエラーが発生しました。どうやら gulp-sass の Scssトランスパイラの指定方法が変わったようです。

対処3 (gulp-sass のScssトランスパイラ指定方法を変更)

const sass          = require('gulp-sass')(require('sass'));
//const Fiber         = require('fibers');

// 略

            .pipe(sass({
//                fiber: Fiber,
                outputStyle: 'compressed',
                quietDeps: true            // 警告回避のために追加
            }).on('error', sass.logError))

// 略

これでようやくタスクが正常に走るようになりました。

参考

puppeteer でファイルをダウンロードするときに、任意のパスと名前で保存する

2021-06-25T03:57:06+09:00

Puppeteer を使ってファイルをダウンロードする際に、任意のパスと名前で保存したい。

残念ながら、現時点ではシンプルな方法は提供されていないようだ。
以下の Issue で何年にもわたって議論されているものの、 「コレ!」 という解決方法は無さそう。
Question: How do I get puppeteer to download a file? · Issue #299 · puppeteer/puppeteer

しかし、この Issue の #issuecomment-668087154 のコメントで、なかなか泥臭い方法で実現するヒントが書かれていた。
これを参考にして、任意のパスと名前でダウンロードファイルを保存してみよう。

実行方法

あらかじめ、 puppeteer の npm パッケージをローカルにインストールしておく。

npm install puppeteer --save

その状態で、後述の .js ファイルを nodejs で実行すれば OK だ。

node puppeteer-download-with-specify-name.js

コードと解説

何をしているのかというと、 GitHub 上の puppeteer のソースコード ZIP ファイルをダウンロードする際に、 Chrome DevTools Protocol を直叩きして、任意のパスとファイル名で保存している。

具体的なポイントは、主に以下の 2点。

Page.setDownloadBehavior メソッドで、ファイルのダウンロードの許可とダウンロード先のディレクトリを指定
Fetch.enable メソッドと Fetch.requestPaused イベントで、ファイルダウンロードのレスポンスに Content-Disposition HTTP ヘッダーを無理やりねじ込む

Content-Disposition HTTP ヘッダーのドキュメントに書かれている通り、 attachment と filename ディレクティブを指定することで、ファイルが（ブラウザ内で表示されるのではなく）ダウンロードが必要であることと、ダウンロード時のファイル名を指定することができる。

但し、 Page.setDownloadBehavior メソッドは実験的で且つ非推奨なので、将来にわたってサポートが続くかどうかはわからない点は、注意だ。
少なくとも、 Chromium 92.0.4512.0 (r884014) では問題なく動いている。

ちなみに、実行する Chromium はヘッドレスモードでもヘッドフルモードでもどちらでも意図通り動くはず。

この方法は Chrome DevTools Protocol に思いっきり依存しているので、 Selenium など他のブラウザ自動化ツールでは同一の方法が難しく (※)、 Puppeteer ならではの方法と言える。
※: Selenium 4.x のプレリリース版を使えば、 Chrome DevTools Protocol にアクセスできるようだが、イベントハンドラを書くのが難しそう？ドキュメントがそろってないのでまだなんとも…

スクレイピング中にファイルをダウンロードする場合などでは、保存先のパスと名前を指定できたほうが良い気がするのだが……
今後の puppeteer や Chrome DevTools Protocol の更新でもっと簡単に実現できるようになることを期待しよう。

Node.jsのPrismaでPrismaClientがimportできない場合

2021-04-07T14:52:38+09:00

Node.jsでPrismaは下記のようにimportする。

import { PrismaClient } from '@prisma/client'

しかしPrismaClientの定義がありません、みたいなことを言われてimportできない。

公式ドキュメントに書いてあるとおり、 prisma generate を実行することでnode_modulesの中に生成してくれるらしい。

npx prisma generate

https://www.prisma.io/docs/concepts/components/prisma-client#2-installation

それでもずっとエラーになってる、という場合はエディタを再起動しよう。

cron から node スクリプトをキックする

2020-12-23T23:56:50+09:00

cron から nodeスクリプトをキックする方法について長らく嵌まっていたのでメモ。

経緯

とあるサーバで markdown-pdf によるPDF生成を行いたくて、自前の nodeスクリプトを作成・運用していました。

ただし、そのサーバは一定期間ごとに再起動をかけているため、その度に自前の nodeスプリプトのプロセスが切れてしまいます。そこで cron で「再起動後に nodeスクリプトをキックする」ようなジョブを書いたのですが……。

@reboot root node /PATH/TO/NODE-SCRIPT/index.js &
30 2 * * 0 root reboot

しかし、上手く行きませんでした。

調査・対処

/var/log/cron で確認すると、 cronジョブ自体は実行されていそうなのですが、 ps aux | grep "node" で確認すると、 node のプロセスはありません。起動できていないようです。

その原因が分からず悩まされていたのですが、ふと node のパスがおかしいのでは、と気付き以下のように修正。

@reboot root /usr/local/bin/node /PATH/TO/NODE-SCRIPT/index.js &
30 2 * * 0 root reboot

※ちなみにこのサーバは n を使って node がインストールされています。

これで試験したところ、再起動後にスクリプトが起動・動作していることを確認できました。

参考

crontabでスクリプトを定期実行する - ブロックチェーンエンジニアとして生きる

BackstopJS で背景画像の高さを `vh` 単位で指定したページで画像やスクリーンショットが引き伸ばされる現象についてメモ (未解決)

2020-12-16T23:42:55+09:00

メインビジュアル等で背景画像の高さを vh 単位で指定したページで、画像やスクリーンショットが引き伸ばされる現象に遭遇してしまいました。正常なスクリーンショットが撮影できないので困った……ということで、その現象について調べたメモです。

調査

調べたらそれと思しき現象の Issues が上がっていました。ただ、どちらも現在進行形でオープンになっているので解決には至っていない模様……。

検証

スレッドの中で提示された対処法:

"mergeImgHack": true, あるいは高さ決め打ちならば "mergeImgHack": 1024, のような値を backstop.json のルートに追記する
beta版を使用する

1.は効果がなかったので2.を試そうと思ったのですが、 Github のブランチ (2.6.7)と npm で指定した場合(4.3.3)で Beta のバージョンが異なる模様。

package.json の dependencies や devDependencies に "backstopjs": "https://github.com/garris/BackstopJS#beta" と指定すると 2.6.7、"backstopjs": "beta", と指定すると 4.3.3 が落ちてきます。

そこで各バージョンで何度か試行錯誤を繰り返しました。

5.0.7:
- 最新版
- 背景画像が引き伸ばされる現象が発生する
- engine で chromy を指定しようとしたところ、 createBitmaps | Chromy is no longer supported in version 5+. Please use version 4.x.x for chromy support. とのこと。 2.6.7 ではそこそこそれっぽい表示になったので engine を切り替えることができれば……と思ったのですが、ダメそうです
4.3.3:
- 背景画像が引き伸ばされる現象の解決には至らず
- いろいろ今どきに近くなっているので各種設定はしやすい
2.6.7:
- 昨日別の場所で試したときは動いたのですが動作再現できず
- 内部的に PhantomJS を使用している模様。2018年に開発終了しているので今更使いたくはない
- 設定を node script から渡すとき、オブジェクトではなくファイルパスを渡す模様。とすると、いったん backstop.json を書き出す処理を挟まないといけない

よくよく先程のスレッドを見直してみると npm install backstopjs@beta とか 4.3.3 と言ったワードがあるので普通に npm 指定の方で良さそうですね。

ひとまず devDependencies に "backstopjs": "beta" を指定してまた色々試してみたいと思います。

備考

Puppeteerによるフルページスクリーンショットを画像遅延読み込みに対応させる - DeNA Testing Blog

スクロールに応じてコンテンツが表示される系のアニメーションもあるので、「下端までスクロールしてからスクリーンショットを撮影する」も対応したいですね……。

追記(2020/12/20)

色々試行錯誤した結果のリポジトリを晒しておきます。

arm-band/test_backstop_randa_back_stopper_2: BackstopJS のテストです。

これは本当、どうしたものか……。

参考

スクリプト

複数枚のスクリーンショットを繋ぎ合わせる

Take screenshot without resizing page ・ Issue #820 ・ garris/BackstopJS

下端までスクロールさせる

Node.js での実行中スクリプトの絶対パス

node.js で絶対パスや相対パスを取得する方法 npm __dirname

続・ Gulp 4 + Webpack 5 を試す (resolutions 使用)

2020-11-24T23:34:09+09:00

以前、Gulp 4 + Webpack 5 を試す ( 未完 / terser-webpack-plugin で TypeError: Cannot read property ‘javascript’ of undefined エラーになる)の記事で Gulp 4 + Webpack 5 の実験をしましたが、その続きです。

経緯

BackstopJS を試す (Error: Failed to launch the browser process! エラー発生→ puppeteer のバージョンを指定して解決)で package.json に resolutions を記述して Yarn で内部依存パッケージのバージョンを強制的に変更する手法を取りましたが、同様の手法が使えるのではないか、と思った次第です。

検証

package.json

```json:package.json
// 略
"devDependencies": {
// 略
"webpack": "^5.6.0",
"webpack-stream": "^6.1.1",
"terser-webpack-plugin": "^5.0.3",
// 略
},
"resolutions": {
"webpack": "^5.6.0"
},
// 略


上述のように `resolutions` で Webpack のバージョンを指定。

### gulp/tasks/js.js

`gulp/tasks/js.js` は前回のまま。

### webpack.config.js

`webpack.config.js` は source map のための設定を追加した以外はそのままです。

```javascript:webpack.config.js
const _         = require('./gulp/plugin');
const dir       = require('./gulp/dir');

const mode = () => {
    return process.env.DEV_MODE === 'dev' ? 'development' : 'production';
};
const modeFlag = () => {
    return process.env.DEV_MODE === 'dev' ? false : true;
};
const entry = () => {
    const entries = _.glob
        .sync(
            '**/*.js',
            {
                ignore: [
                    '_plugins/**'
                ],
                cwd: dir.src.js
            }
        )
        .map(function (key) {
            return [key, _.path.resolve(dir.src.js, key)];
        });
    return Object.fromEntries(entries)
};
const configs = {
    mode: mode(),
    entry: entry(),
    output: {
        filename: '[name]'
    },
    optimization: {
            minimizer: [
            new _.webpackTerser({
                extractComments: 'some',
                terserOptions: {
                    compress: {
                        drop_console: modeFlag(),
                    },
                },
            }),
        ],
    }
};
if (process.env.DEV_MODE === 'dev') {      // 追加
    configs.devtool = 'inline-source-map';
}

module.exports = configs;

これで yarn restart などすると

$ gulp

# 略

[hh:ii:ss] asset app.js 226 KiB [emitted] [minimized] (name: app.js) 1 related asset

webpack 5.6.0 compiled successfully
[hh:ii:ss] Finished 'jsBuild' after 20 s

動きました！

後々は resolutions なしでも動くようにしたいですが、ひとまず動く形になったのでメモしておきます。

参考

Yarn の reasolutions

yarn: resolutions で依存の依存のバージョンを指定する - nju33

Gulp 4 + Webpack 5 を試す ( 未完 / terser-webpack-plugin で TypeError: Cannot read property 'javascript' of undefined エラーになる)

2020-11-24T23:28:18+09:00

以前、browserify + babelify + Gulp で IE11対応を試すの記事で browserify + babelify を試しましたが、今回は Webpack に挑んでみます。

ただし、プレーンな Gulp 環境ではなく、 Ususama で。

コード

package.json

// 略
    "devDependencies": {
// 略
        "glob": "7.1.6",
        "webpack": "^5.1.3",
        "webpack-stream": "^6.1.0",
        "terser-webpack-plugin": "^5.0.0",
// 略
    }
// 略

gulp-uglify-es と gulp-concat を除き、代わりに webpack 本体と Gulp で Webpack を使用するために必要な webpack-stream 、そして minifier の terser の Webpack 用プラグインである terser-webpack-plugin を追加。

gulp/tasks/js.js

const gulp          = require('gulp');
const plumber       = require('gulp-plumber');
const notify        = require('gulp-notify');
const webpack       = require('webpack');
const webpackStream = require('webpack-stream');
const rename        = require('gulp-rename');
const dir           = {
    dist: {
        js: './dist/js'
    }
};

const webpackConfig = require('../../weppack.config');

const jsBuild = () => {
    return _.webpackStream(webpackConfig)
        .pipe(_.plumber({
            errorHandler: _.notify.onError({
                message: 'Error: <%= error.message %>',
                title: 'jsLibBuild'
            })
        }))
        .pipe(_.rename((path) => {
            path.basename += '.min'
            path.extname = '.js'
        }))
        .pipe(_.gulp.dest(dir.dist.js));
};

module.exports = jsBuild;

webpack.config.js

const webpack       = require('webpack');
const webpackTerser = require('terser-webpack-plugin');
const path          = require('path');
const glob          = require('glob');
const dotenv        = require('dotenv').config();
const dir           = {
    src: {
        js: './src/js'
    }
};

const mode = () => {
    return process.env.DEV_MODE === 'dev' ? 'development' : 'production';
};
const modeFlag = () => {
    return process.env.DEV_MODE === 'dev' ? false : true;
};
const entry = () => {
    const entries = _.glob
        .sync(
            '**/*.js',
            {
                ignore: [
                    '_plugins/**'
                ],
                cwd: dir.src.js
            }
        )
        .map(function (key) {
            return [key, _.path.resolve(dir.src.js, key)];
        });
    return Object.fromEntries(entries)
};
module.exports = {
    mode: mode(),
    entry: entry(),
    output: {
        filename: '[name]'
    },
    optimization: {
            minimizer: [
            new _.webpackTerser({
                extractComments: 'some',
                terserOptions: {
                    compress: {
                        drop_console: modeFlag(),
                    },
                },
            }),
        ],
    }
};

いくつかの記事を参考にしながらタスクを組みます。

自分でカスタマイズした部分は以下。

.env で dev, demo, prod のモードを切り替えているので、その部分を process.env.DEV_MODE で振り分け
- Webpack の設定の mode と terser-webpack-plugin の drop_console のフラグが関係しています
複数の .js ファイルをエントリポイントにしたかったのでその部分はwebpackのentryファイルを複数指定、globパッケージの使い方 - Qiitaを参考に
最終的なファイル名は XXX.min.js の形にしたかったので gulp-rename を通しました

jQuery の扱い

タスク自体は上記のやり方で走ることが確認できました( DEV_MODE=dev )。

次は現時点ではまだ jQuery を使用しているので、 jQuery をどう読み込ませるかが課題ですが、以下のようにして動作することを確認しました。

app.js

import $ from 'jquery';
import 'jquery.easing/jquery.easing';

$(() => {
    /* 処理 */
});

sitesearch.js

import $ from 'jquery';
import List from 'list.js';

//サイト内検索
export default () => {
    const options = {
        valueNames: ['searchTitle', 'searchText'],
    };
    const searchList = new List('listSearch', options);
    //hits
    searchList.on('searchComplete', function (a) {
        $('#hits').text(a.matchingItems.length);
    });
};

サイト内検索で List.js を使用しているのですが、これについてはHow am I suppose to import list.js with es6 and webpack ? · Issue #559 · javve/list.jsの Issues の方法で解決しました。

ここまでは比較的順調でした。

しかし、間も無く壁に突き当たることになります……。

TypeError: Cannot read property 'javascript' of undefined エラー

DEV_MODE=dev で動作することは確認できたので、 DEV_MODE=prod に切り替えました。

すると、以下のエラーが出てしまいました。

TypeError: Cannot read property 'javascript' of undefined
    at PATH\TO\PROJECT\node_modules\terser-webpack-plugin\dist\index.js:366:38

DEV_MODE=dev に戻すと先ほどと同じように問題なく動作。上記でこのフラグが関係するのは mode と terser-webpack-plugin の drop_console の2箇所なので、そのどちらかだろうとアタリを付けます。

試しに drop_console を常に false としましたが、 DEV_MODE=prod でエラーは再現しました。

となると、 mode の方ということになります。

ここでエラー文で検索すると、以下の Issues を発見。 terser-webpack-plugin 本家のリポジトリです。

TypeError: Cannot read property 'javascript' of undefined ・ Issue #335 ・ webpack-contrib/terser-webpack-plugin

発生個所も含めてエラー文が同じです。

別の方のコメントを見ると、原因は以下の模様。

terser-webpack-plugin 5 は Webpack 4 とは互換性がない
webpack-stream の内部で使用している Webpack がバージョン 4 系

yep, we are working on it, release with fix will be today/tomorrow

TypeError: Cannot read property 'javascript' of undefined ・ Issue #335 ・ webpack-contrib/terser-webpack-plugin (2020/10/16日 22:04 JST)

わりとタイムリーなものを踏んでしまったようなので、 fixed されるのを待つ感じですかね……。

webpack-stream - npm

Webpack, 複数エントリポイントとoutput

webpackのentryファイルを複数指定、globパッケージの使い方 - Qiita

List.js import

How am I suppose to import list.js with es6 and webpack ? · Issue #559 · javve/list.js

terser-webpack-plugin

TypeError: Cannot read property 'javascript' of undefined ・ Issue #335 ・ webpack-contrib/terser-webpack-plugin