chilitreat blog

開発,プログラミング,趣味系をまとめます.Qiitaと差別化したい

typescript-eslintの導入方法とディレクトリごとにルールを設定する方法

メモがてから自分用に使い方をまとめて見る。 少し前まではTypeScript本体やESLintと@typescript-eslintのバージョンを揃えないと一気に設定が壊れる印象だったが最近は安定してそう

検証したバージョン

  • npm v6.13.4
  • Node.js v10.19.0
  • typescript v4.3.5
  • eslint v7.32.0
  • @typescript-eslint/eslint-plugin v4.29.2
  • @typescript-eslint/parser v4.29.2

typescript-eslintはがサポートしているTypeScriptのバージョンは >=3.3.1 <4.6.0(2022/01/09現在)

導入方法

基本的に公式のGet Startedに書いてある通り

Linting your TypeScript Codebase | TypeScript ESLint

インストール

npm install --save-dev eslint typescript @typescript-eslint/parser @typescript-eslint/eslint-plugin

.eslintrc.js の設定

プロジェクトルートに、.eslintrc.js という名前でファイルを作成。以下をコピー&ペーストする

package.jsonに設定を書くこともできるが、eslintrc.jsに書く方がゴチャらないので好み

module.exports = {
  root: true,
  parser: '@typescript-eslint/parser',
  plugins: [
    '@typescript-eslint',
  ],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
  ],
};

ちなみに、eslintrc.js以外にも様々なファイル名(拡張子)が使用可能
JSONでもYAMLでもコメントが書けるのでどれを選ぶかはお好みで

  • .eslintrc.js
  • .eslintrc.cjs
  • .eslintrc.yaml
  • .eslintrc.yml
  • .eslintrc.json
  • ( package.json )

eslint.org

eslintrcの各設定項目の意味を解説する

root: true

ESLint実行時、解析されるファイルと同じディレクトリ階層にeslintrcが存在した場合は、そのeslintrcに記載された設定が優先される(後勝ちの設定

root: true と記載されたeslintrcが見つかるまで子ディレクトリから親ディレクトリへ走査する。途中で見つからない場合は ルートディレクトリまで走査する

プロジェクトルートのeslintrcにroot: trueと記載すると、親ディレクトリ以上は走査しないため意図しない設定のマージが防げる

eslintrcとpackage.jsonが同じ階層にあった場合は、eslintrcが優先され、package.jsonは無効化される

parser:

ESLintがTypeScriptの構文を解釈できるように@typescript-eslint/parserを指定する

plugins:

インストールしたプラグインを読み込ませるために@typescript-eslintを指定する

extends:

予め用意された設定を拡張として読み込む eslint:recommended, plugin:@typescript-eslint/recommended, の二つを記載することで、いい感じに設定された推奨ルールを読み込んでいる

extends の設定方法に色々なパターンがあるが、この記事がとても分かりやすかった

zenn.dev

■ 他に設定できること

rules, ignorePatternsなどが設定可能

詳細はこちらを参照 eslint.org

基本的な設定項目

eslint:recommended で設定されているルール

このページの一番左列に✔︎マークがついている項目

eslint.org

plugin:@typescript-eslint/recommended で設定されているルール

このページの✅列に✅マークがついている項目

typescript-eslint.io

plugin:@typescript-eslint/eslint-recommended

plugin:@typescript-eslint/recommended の中で extendsされている

https://github.com/typescript-eslint/typescript-eslint/blob/97c0e8606705dc0b4ef8b4ee5206111276c8a170/packages/eslint-plugin/src/configs/recommended.ts#L6

この記事でも言及されているように、plugin:@typescript-eslint/recommendedが指定されている場合は、追加でextendsさせる必要は無い

zenn.dev

ディレクトリごとにルールを設定する

TypeScriptで書かれたバックエンドアプリケーションを想定

基本的にキャメルケースで統一しつつも、データベースのインタフェースのプロパティ名はスネークケースで定義するeslintrcの設定をする

- `app/**/*.ts` のinterfaceの属性名をキャメルケースに設定する
- `app/infrastructure/database/*.ts` のinterfaceのプロパティ名をスネークケースに設定する

命名規則を設定するには、@typescript-eslint/naming-convention を適用する

typescript-eslint/naming-convention.md at main · typescript-eslint/typescript-eslint · GitHub

しかし@typescript-eslint/naming-convention のルールだけでは、特定のディレクトリ配下のファイルにだけ別のルールを適用することができない

github.com

そのため、

  • orverridesを指定してルールを上書きするか
  • 別のルールを適用したいファイルが存在するディレクトリに、.eslintrcを配置するか のどちらかで解決する必要がある。

今回は前者のorverridesを指定してルールを上書きする方で解決する

先ほど作成した eslintrc.jsに以下を追記する

...
rules: {
  "@typescript-eslint/naming-convention": [
    "error",
    { 'selector': 'property', 'format': [ 'camelCase' ] }    // Group Selectorsの property。classProperty, objectLiteralProperty, typePropertyをキャメルケースで指定する
  ]
},
overrides: [
  {
    "files": [ "app/infrastructure/database/*.ts" ], // 上書き対象のGlobパターン
    "rules": {
      "@typescript-eslint/naming-convention": [
        "error",
        { 'selector': 'property', 'format': ['snake_case'] }
      ]
    }
  }
]
...

全てファイルに { 'selector': 'property', 'format': [ 'camelCase' ] } のルールが適用されて困る場合は、orverridesに解析を無視するGlobパターンを記載すれば良い

...
rules: {
  "@typescript-eslint/naming-convention": [
    "error",
    { 'selector': 'property', 'format': [ 'camelCase' ] }    // classProperty, objectLiteralProperty, typePropertyをキャメルケースで指定する(Group Selectors)
  ]
},
overrides: [
  {
    "files": [ "app/infrastructure/database/*.ts" ],
    "rules": {
      "@typescript-eslint/naming-convention": [
        "error",
        { 'selector': 'property', 'format': ['snake_case'] }
      ]
    }
  },
  // ここ追加
  {
    "files": [ "app/infrastructure/api/*.ts" ], // apiは外部APIの仕様によって様々なので無視する
    "rules": {
      "@typescript-eslint/naming-convention": [
        "off",
        { 'selector': 'property', 'format': [ 'camelCase' ] } // rulesに書いたルールを指定する
      ]
     }
  }
]
...

このeslintrcを設置することで、ディレクトリごとに異なるルールが設定可能になった

すでに開発が進んでいるプロジェクトで導入する際は、全ファイルで共通したルールを設定した後、ディレクトリごとにルールを無効化するルールをorveridesに追加し、徐々に無効化したルールを有効化してくと比較的辛くなく導入できるはず

コードレビューで好みをの話をされるとモヤるのでLintを整備して秩序と安寧を作っていきたい

参考情報

  1. Configuration Files - ESLint - Pluggable JavaScript linter
  2. ESLint 設定を作成する技術
  3. ESLintでTypeScriptの変数の名付け規則をチェックしよう! | DevelopersIO
  4. うわっ...私の.eslintrc、無駄が多すぎ...?
  5. [naming-convention] Cannot disable individual rule options · Issue #2755 · typescript-eslint/typescript-eslint · GitHub

EPOMAKER EP84購入と初めてのキースイッチルブ レポ

2022年もよろしくお願い致します。(生きてます)

EPOMAKER EP84とキーボード用品をいろいろ買い漁った際のレポ記事です

EPOMAKER EP84 購入(¥8,850)

最終的に真っ白なキーボードにしたいので白色で、重めのリニア軸が欲しかったのでGateron Black軸を選びました。

2021年12月22日に注文して12月30日に届きました。

商品ページのお届け予定日では、2022年1月7~14日の間だったのでかなり早く届けてもらえました。感謝

合わせて買ったもの

開封ログ

海外からの輸送だったが箱潰れ無し 

付属品はキープラーとスイッチプラーとケーブル(Type-C to Type-A)

ゲーミングっぽく光るがダサいので使わない

単色は使うかも

元々スタビライザールブされていました。今回スタビライザールブもやってみようと思いましたが、結局やりませんでした。

サウンドテスト

改造前の買ったままの打鍵音を録音してみました。

実際に聞こえる音はMarantz MPM-2000Uで録音した音に近い印象です。


www.youtube.com

感想

  • デフォルトの状態でもそこそこ満足
  • 不満点を挙げるなら
  • キーキャップの角がしっかり四角い
    • 慣れの問題だと思うがちょっと痛い
    • 個人的には若干カーブしてる方が好み
  • スペースキーが若干カタつく
    • スタビライザーの芯が微妙に沿っている?

今回やること

  1. キーキャップ交換 + 静音化リング装着
  2. キースイッチルブ + テープMod + スタビライザーとプレートの間にサージカルテープを貼る (この工程なんて名前なんだ...)

1. を実施した後に、2.を実施します。

1. キーキャップ交換 + 静音化リング装着

元々はChoco60につけていた NP PBT Crayonを EP84に付け替えた

スタビライザーに刺さる部分へは静音リングをつけてません。

f:id:dendenden00:20220104225558j:plain

サウンドテスト


www.youtube.com

感想
  • 静音リング2個で打鍵感は結構変わる
    • キーの沈み込みが結構浅くなりました
    • 静音スイッチのようなモニョっとした打鍵感になり若干メンブレン式っぽい
    • 押下時、戻り時の高音が削られた(気がする)
  • キーキャップが可愛い
    • 見た目大事

2. キースイッチルブ + テープMod + スタビライザーとプレートの間にサージカルテープを貼る

初めてのルブなのでこの記事を参考にさせていただきました

ggjpn.com

稀にPCBから抜けないスイッチが1,2個あり、力任せに引き抜いたら若干欠けました...

サウンドテスト

若干Macbook Proのファンの音が入ってしまいました。


www.youtube.com

感想
  • 打鍵感がより重めになった
    • 潤滑剤を塗りすぎた可能性?
    • 静電容量無接点 + メカニカルの中間のような打鍵感になりました
  • 打鍵音ピタピタからトコトコへ
    • より上品な音になりました
  • キーボード自体の反響音が極小に
    • プラスチックケースですがテープModの効果は思った以上にある印象です

まとめ

合計費用: ¥14,206

ホットスワップ可能なキーボードですし、これからキーボードを学んでいくのにちょうどいい価格帯ではないでしょうか?

今回静音化がうまくいかなかったら静音スイッチを購入しようと思っていましたが、大満足な仕上がりになったのでしばらくはこのまま運用してみます

 

もうすぐ Kickstarterで支援したMojo68も届きそうなので、届いたらサウンドテスト記事を書こうと思います。

 

最後まで読んでいただいてありがとうございました。2022年もよろしくお願い致します。

2021年6月の月報

f:id:dendenden00:20210630223631p:plain
やるやる詐欺現場

やったこと

  1. 初めてLaravel Package開発した
  2. 副業始めた
  3. 応用情報落ちてた

初めての経験がいっぱいあるので嬉しい

わかったこと

1. 初めてLaravel Package開発した

最近PHP案件のお声がけをいただくことがちらほらあるが、PHP全くの初心者なのでお断りすることがあり申し訳ないなと思い、 本業務でちょうど良さげなPHP案件があったのでやってみた。

最後の最後でREADME.mdに書いてある通りにビルドできないトラップを踏んで、工数を浪費する経験をした。
Contributorが退職者だらけのリポジトリを触るときは実装、テスト工数だけじゃなく調査工数なども積むようにしようと誓った。

2. 副業始めた

業務委託としてお手伝いさせていただいている。(人脈は大事)

平日も毎日1時間ぐらい働けるだろうと思っていたが、全然稼働時間取れなかった。

業務内容としては、Ruby on Rails、Nuxt.js あたりをがっつり書いている。

Railsは初めてだったので、慣れるまでは辛かったが徐々に慣れてきた。

Railsの規約がいい感じにやってくれることが多いので、あんまり本質的な理解をしないままそれらしい処理が書けてしまう。

Shrine と格闘しているが、バックグラウンド処理で動画ファイルをトランスコードする方法がわかってない

shrinerb.com

pug, scss, Vuex ORMなど初めての文化に触れることが多く刺激的な毎日で本業より楽しいまである。

初心者な自分が楽しく開発できるのは、開発以外のスケジュール調整やタスクの洗い出しを行っていただいてるからなので感謝の気持ちを忘れずに続けていきたい。

3. 応用情報落ちてた

f:id:dendenden00:20210630225553p:plain
夏の風物詩になりつつある

試験会場が所沢だったので朝の移動が大変だった

秋も受けよう(次はさいたま市のどこかで受けたい

次やること

  • ビルド環境のコンテナ化で属人化を防ぐ
  • Effective Ruby読む

今月買ったもの

f:id:dendenden00:20210630232352j:plain
A Pocket-sized Ergonomic MacBook Stand & 8-in-1 USB-C Hub

これ

https://www.kickstarter.com/projects/joyroom/a-pocket-sized-ergonomic-macbook-stand-and-8-in-1-usb-c-hub

f:id:dendenden00:20210630232359j:plain
Macbook Proにつけるとこんな感じ

デザインかっこいいけど、素材のプラスチック感が否めない。

f:id:dendenden00:20210630232033j:plain
マキネッタ

低脂肪牛乳でカフェオレ作ると美味いというツイートを見て真似した

f:id:dendenden00:20210630232612j:plain
揖保乃糸(特級)

確かに美味いけど、そこまで感動は無かった(400円ぐらい)

在宅ワークになって1週間が経った

変わったことは無数にあるので、良かったことだけを振り返る

脱東京をした

在宅ワーク発令が出てから、数日後に東京を脱した。 理由としては、東京にいる意味が無くなったからだ。 東京で働く動機は、 * 他のエンジニアからの刺激を受けならがら働く * 勉強会やイベントに参加する この辺くらいしかない。 コロナの影響で勉強会系のイベントがバタバタなくなっているので悲しい。

そんなこんなで、今は宮城から在宅ワークをエンジョイしてる。良い

通勤がなくなった

今まで職場で働くことが嫌だと思っていたが、6割くらいが通勤に対する不満だった気がする。 普段の出勤では、ピーク帯を外して通勤しているがそれでも決まった電車に乗らなきゃいけないという自分ルールが辛い

今は毎朝6時半ごろに起床して、8時から仕事を始めている。以前に比べて生活リズムが圧倒的に改善された。 普段は19時ごろに仕事を終えるが、19時は帰宅ラッシュに巻き込まれるのであと30分仕事しようみたいな謎調整いらずで仕事を終えられるのが最高。

周りに影響されにくくなった

自分のようなジュニアクラスのエンジニアにとっては、成長の機会損失とトレードオフな気がするが、、、

ストレスに感じる周りの声がなくなったのは結構心が健康になった気がする。 5分ミーティングしたいときの「ちょっといいですか?」をする機会は減った気がするが、以前が異常に多かったのかもしれない

終わりに

「明日から在宅ワークお願いします!」と経営層からお達しがあり現場は混乱しながらも無理矢理在宅になったわけだが、当初は業務にならない事もあったが1週間経つとほぼ全ての業務が在宅でも対応できるようになった。

17時に仕事を終え、晩ご飯の準備をして、散歩をして、洗濯をして、風呂に入り、11時頃にはベッドに入る生活をしている。普通のことだが幸せに感じる

在宅勤務が快適すぎて普段通りの出社をするのが無理かもしれない

転職活動が滞っている(死活問題)