私が歌川です

@utgwkk が書いている

create-react-app --template typesctiptの直後に初手で入れる設定

はじめに

Reactでアプリケーションを作るときは、だいたい create-react-app --template typesctipt してから開発を始める。ゼロコンフィグでReactアプリケーションを書けて便利だけど、もうちょっと手を入れておくと快適に開発できるようになる。

趣味の個人開発で create-react-app --template typescript した直後にやっている設定を紹介する。集団開発だとまた変わってくる項目もありそう。

バージョン情報

  • create-react-app 4.0.3

設定していること

ESLint

package.jsonの eslintConfig を以下のように書き換える*1

@typescript-eslint/explicit-module-boundary-types は、exportする関数の型を明示すべきというルール。型推論とエディタの補完でなんとかなっているので無効にしている。コードの規模や開発メンバーの人数によっては、明示したほうがスムーズにいく場合もあるかもしれない。

ほかにも有効にしておくとよいルールがあるかもしれないけど、今のところ手癖で回避できているので、あまり設定項目を増やしていない。

ESLintとprettierをくっつける動きもありそうだけど、やってない。VSCodeの設定でコードの見た目が勝手にフォーマットされるようにしている (後述) し、強制したいならhuskyとか導入したらいいと思う。

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest",
      "plugin:@typescript-eslint/recommended"
    ],
    "rules": {
      "@typescript-eslint/explicit-module-boundary-types": "off"
    }
  },
2021/7/14 18:24 追記

create-react-app --template typesctiptの直後に初手で入れる設定 - 私が歌川です

あれ?「react-hooks/exhaustive-deps」は特に何もしなくてもデフォルトで有効になってない?(react-scripts、v4.0.3で確認

2021/07/14 18:10
b.hatena.ne.jp

手癖で足していたけど、改めて手元で確認してみると "plugins": ["react-hooks"]rules の設定はなくてもデフォルトで有効になっていた。

ご指摘ありがとうございます。記事中でも明示的に設定しないように修正しました。id:Rishatang

prettier

インポート順のソートが自動で行われてほしいので、@trivago/prettier-plugin-sort-importsを導入する。

$ yarn add -D @trivago/prettier-plugin-sort-imports

package.jsonに prettier というキーで以下を追加する。

  "prettier": {
    "importOrder": [
      "^[./]"
    ],
    "importOrderSeparation": true
  },

このように設定することで、以下のようにインポートが分けてソートされる。

  • 依存ライブラリのインポート
  • 異なるディレクトリ以下のファイルのインポート
  • 同一ディレクトリ以下のファイルのインポート

.eslintignore, .prettierignore

自動生成したファイルをlintしなくてよいし、整形されたら困るので対象外にする。

.eslintignore.prettierignore を以下の内容で保存する。relayが自動生成するファイルをignoreしている。

__generated__/

editorconfig

最終的にはprettierでフォーマットするけど、新規作成したファイルが4スペースインデントになったりしてイライラすることが多いので、前もってeditorconfigで制御しておく。

リポジトリルートに .editorconfig を以下の内容で設置している。

root = true

[*.{ts,tsx}]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

VSCodeの設定ファイル

.vscode/settings.json に以下の設定を書く。Format on Saveを有効にしているだけである。

{
    "[typescript]": {
        "editor.formatOnSave": true
    },
    "[typescriptreact]": {
        "editor.formatOnSave": true
    }
}

設定していないこと

husky, lint-stagedでのコミット時コード整形

huskyやlint-stagedを使うと、git commit のタイミングでstagedな差分を整形できるけど、やっていない。個人開発の範囲だと、VSCodeのFormat on SaveやAuto Fixで事足りている。

VSCodeの推奨拡張機能の設定

チームで開発するなら .vscode/extensions.json を設置してもよいかもしれない。editorconfig, ESLint, prettierを使うための拡張機能をおすすめする設定を書くなら以下のようになる。

{
    "recommendations": [
        "editorconfig.editorconfig",
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode"
    ]
}

tsconfig.json の設定

create-react-app --template typescript で出力されたものをそのまま使っていて、特に困っていない。

おわりに

create-react-app --template typescript した直後に導入している設定を紹介してきた。

毎回初期化後に既存のリポジトリからコピペして設定しているけど、ひと通り設定済のものをcreate-react-appのテンプレートとしてアップロードしておけば、コピペしなくて済むようになって便利な気がする。

*1:ここから読み取れるように、package.jsonにどんどん書き足していく派である。設定項目が増えたらファイルを分けてもいいと思う。

perlcriticのポリシーの一覧を見れるようにしたい

metacpanのAPIを使う作戦 (断念)

metacpanにはAPIがあるので、これを活用できないか考えます。

curl 'https://fastapi.metacpan.org/v1/module/_search?q=distribution:Perl-Critic&size=5000' というコマンドを実行することで、metacpanからPerl-Criticディストリビューションに含まれるモジュールの一覧を取得できます。pod というフィールドが含まれているのでこれが使えそうです。

が、この pod フィールドには、連続する空白文字をスペースに変換したPODの文字列が含まれています*1。テキストエディタの拡張機能などから使うぶんにはこれでもよいかもしれませんが、一覧として見るにはちょっと使いづらそうです。

手元にインストールしたモジュールのPODを抽出する作戦

metacpanのAPIを叩かなくても、手元にインストール済のperlcriticのポリシーのPODを抽出すればよいことに気づきました。 Pod-Markdownディストリビューションに含まれる pod2markdown コマンドでMarkdownに変換しておけば取り回しがよさそうです。

Perl::CriticとPod::Markdownを手元にインストールしたあと、以下のようなスクリプトを回すことで、perlcriticのポリシー一覧のドキュメントを生成できます。Perl::Critic::Policy以下のモジュールを取得するためにいきなり find コマンドを使ったり、Pod::Markdownのインスタンスを作らずに文字列操作でゴチャゴチャやったりしています。

# generate-perlcritic-policies.pl
use strict;
use warnings;
use utf8;
use feature 'say';

sub filename_to_package {
    my $filename = shift;
    my ($pkg) = $filename =~ m{lib/perl5/([0-9a-zA-Z_\/]+)\.pm$};
    $pkg =~ s{/}{::}g;
    $pkg;
}

# モジュールのパスは手元の環境に合わせて書き換える
my @policy_files = split /\n/, `find ~/perl5/lib/perl5/Perl/Critic/Policy -type f -name '*.pm'`;

for my $policy_file (@policy_files) {
    my $markdown = `pod2markdown $policy_file`;
    $markdown =~ s/^#/##/mg;

    my $pkg = filename_to_package($policy_file);
    say "# [$pkg](https://metacpan.org/pod/$pkg)";
    say "";
    say $markdown;
}
$ perl generate-perlcritic-policies.pl > policies.md

こうして生成したMarkdownファイルを適当なところに置いておくとよさそうです。

退勤して、ラーメンを食べてベッドに倒れ込んだら猛烈な眠気が襲ってきた。朝の5時ぐらいに目覚めてインターネットをしていたのと、仕事の疲れがあったのとが重なったのだろう。


冷感シートが届いたので試してみたところ、たしかにちょっと冷える気がする。が、汗はしっかりかくのでもうちょっと調整が必要そう。

テストケースと野生の勘

コードを書いていたりコードレビューで実装を眺めたりしていて、こういうケースでもうまく動いてほしいけど落ちそう、と思ってテストケースを足すと実際にテストが落ちる、ということがしばしばある。はたから見ると野生の勘とか嗅覚みたいな感じになりそうだけど、コツはあるはず。

条件分岐や追加された実装からアタリをつけるのは1つのコツだと思う。実装が増えるということは、考慮しないといけない場合が増えるということである。追加された実装を起点に、考慮漏れがないかを探ってみる。エッジケースに見えるかもしれないけどありうるユースケースを考えて、それを実現するテストケースを足して、テストを走らせてみる。落ちればアタリだし、落ちなくても保険としてテストケースを足しておくのがよいと思う。競技プログラミングをやっている人にとっては、撃墜ケースみたいな形で言語化されていそう。

アプリケーションの核となる機能や、壊れると体験を著しく損うので壊れてほしくないようなパーツには、相応のテストがあるとよさそう。なんでもアサーションするべきというよりは、最も保証したい性質を確かめていくというイメージでやっている。確かめていたつもりだけど実は不十分だった、ということにあとから気づくこともあるけど、気づけるようになるのが尊いと思う。


以前も野生の勘について書いていた。野生の勘が言語化・体系化されてパターンになっていくのだろう、と考えている。

blog.utgw.net

緊急事態宣言

まずはこちらをご覧ください。

この写真を再現したくなり、緊急事態宣言ジェネレーターを作る運びとなりました。

「緊急事態宣言」の文字が大きすぎて折り返されると、無料ジャバのダウンロード感が出てきてしまうので、できるだけ折り返されないように注意しました。vwやvhを駆使しています。スマホで見てもひどいことにはならないと思うけど、縦画面で見てもわけがわからないと思います。

ほんとうはスクランブル交差点の写真を使いたかったけど、権利的にクリーンにしたいので、去年撮影した大阪の写真をデフォルトで表示するようにしています。

好きな写真で緊急事態を宣言したくなった際にご利用ください。glitchで作って、remixボタンもあるので誰でも自由に改造できます。もっとかっこいい緊急事態宣言にしてください。

2021/7/8 10:15 追記

suzusime-log.hatenablog.jp

もっとかっこいい緊急事態宣言が作られました。CSSの filter でSVGフィルタが使えることを (そもそもSVGフィルタ自体も) 知らなかったです。使いこなせるとどう考えても便利ですね。

2017/7/8 11:02 追記

blog.sushi.money

現代はCSSでできることが増えていて便利な時代になりましたね。CSSアニメーションだけでなめらかにアニメーションさせやすい属性とそうでない属性がありそう。

あ、これは切ったわ、と思ったときにはすでに切り込みが入っていた。絆創膏を貼ったところを夕方になって剥がしたらシワシワになっていた。


雨が続いていてなかなか洗濯できずにいる。バスタオルが尽きたのでちょっとずつ洗濯機を稼動させて干してみているけど、今日はとくにひどい雨だったのでぜんぜん乾いてなかった。乾燥機を導入しないといけないのであろう。


気がついたら手にラメ (マニキュア?) を塗られていて、そのまま何週間か過ごしたけどまだちょっと残っている。ほんとうは除光液かなにかを使うのがよいのだろうけど、まあもういいか。