node/browser環境での重複確認用ハッシュ文字列生成メモ

emotionのdata-属性で使っているような値が欲しかった。 emotionは@emotion/hashとして持っているものの、内部用かなぁと思うのでmurmurhashを使ってみた。 TextEncoderを使っているので環境によりpolyfillが必要。

import murmurhash from "murmurhash";

function hashString(s) {
    return murmurhash.v3(s).toString(36);
}

console.log(hashString("hfogfffe")); // 6bmwh9

参考

• 高速ハッシュアルゴリズム – YOSBITS

tmuxで複数の開発サーバーを一括で起動する

Next.jsを複数動かす必要があったり、SPAをwatchしつつバックエンドも起動しておく、みたいな開発環境の場合、ひとつひとつ立ち上げるのは手間なので、tmuxで一括起動するスクリプトを作った。バックエンドは左にでかく、フロント達は右に、みたいなのは考慮せず、縦に並べるだけ。

yalcを使って開発中のnpmパッケージを手元で確認する

ライブラリとして分離したnpmパッケージを作るときは、シンプルなものであればyarn linkでローカルファイルを参照しながら動作確認ができるのだけど、依存によってはややこしい問題が起きたりする。

例えばReactを使うライブラリだとこんなエラーが起きたりする。

Error: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://fb.me/react-invalid-hook-call for tips about how to debug and fix this problem.

そこで登場するのがyalcというツール。yarn linkはざっくり言うとライブラリ側のディレクトリへのシンボリックリンクをアプリ側のnode_modules以下に配置するのに対して、yalcを使うとローカル(~/.yalc)にpublishしてそこをpackage.jsonで見る形にできるので、npm registryにpublishされたものを使うのに近い状態にすることができる。

使い方

1. yalcのインストール

yalc自体をインストールする。

$ yarn global add yalc

2. publish

ライブラリ側でyalc publishする。

$ cd ~/proj/mylib
$ yarn build とか
$ yalc publish

3. パッケージ追加

アプリ側でyalc addする。

$ cd ~/proj/myapp
$ yalc add @myorg/mylib
$ yarn

これで使えるようになる。package.jsonにはこんな感じのエントリが追加されている。

    "@myorg/mylib": "file:.yalc/@myorg/mylib",

4. 内容更新

中身を変えたら publish と update をする。

$ cd ~/proj/mylib
$ yarn build とか
$ yalc publish
$ cd ~/proj/myapp
$ yalc update

5. yalc remove

yalc remove --allしておしまい。

$ cd ~/proj/myapp
$ yalc remove --all
$ yarn

詳しくはyalcのGitHub (https://github.com/whitecolor/yalc)を参照。

SPA用にwebpack-dev-serverにproxyを設定する

SPA (Single Page Application) でWebアプリケーションを作る場合、HTMLの生成やREST APIはJavaScript/CSSの配信とは別のサーバーで行うものの、クラウド環境ではCloudFrontなりリバースプロキシなりが存在していて、結果全て同一ドメインで運用されていることがある。

この状況で、JavaScriptをローカル環境のwebpack-dev-serverで試験しようとすると、REST APIが別ポートになるのでローカル環境でだけCORSの設定が必要だったり、深いパスでリロードするとNot Foundになったりといったような面倒ごとが発生する。

これを解決するには、nginxなりでproxyを立てても良いが、webpack-dev-serverにもproxyの機能がついているので、以下のように設定すると簡単。

    devServer: {
        contentBase: 'dist',
        host: '0.0.0.0',
        port: 3000,
        proxy: {
            '/myapp/api': {
                target: 'http://127.0.0.1:9292'
            },
            '/myapp': {
                target: 'http://localhost:3000/examples/index.html',
                pathRewrite: {'^.*' : ''}
            }
        }
    }

examplesにローカル向けのindex.htmlを置いておいて、CopyWebpackPluginでコピーすると便利。

        new CopyWebpackPlugin([
            { from: 'examples', to: 'examples' }
        ]),

gulp.watchで新規ファイルを処理させるにはパスを./で始めない

ファイルに変更があるとタスクを処理してくれるgulp.watch。こんな感じに書いてある記事を見かけることがあるけど、これだと新規に.jsファイルを追加した場合、処理してくれない。

gulp.watch('./js/*.js', ['browserify']);

そんなもんか？と思っていたけど、./を消せば見つけてくれる。

gulp.watch('js/*.js', ['browserify']);

追いかけてないけど、なんだろうね？

参考：Globs beginning with ./ doesn't capture file events

上のスクリプトの全体はこんな感じ：