typescript-eslintの導入方法とディレクトリごとにルールを設定する方法
typescript-eslint、たまにしか触らないので毎回0から調べてる気がする(そして毎度詰まる
— chilitreat (@chilitreat) January 8, 2022
メモがてから自分用に使い方をまとめて見る。 少し前までは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の各設定項目の意味を解説する
■ 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 の設定方法に色々なパターンがあるが、この記事がとても分かりやすかった
■ 他に設定できること
rules, ignorePatternsなどが設定可能
詳細はこちらを参照 eslint.org
基本的な設定項目
eslint:recommended
で設定されているルール
このページの一番左列に✔︎マークがついている項目
plugin:@typescript-eslint/recommended
で設定されているルール
このページの✅列に✅マークがついている項目
plugin:@typescript-eslint/eslint-recommended
plugin:@typescript-eslint/recommended
の中で extendsされている
この記事でも言及されているように、plugin:@typescript-eslint/recommended
が指定されている場合は、追加でextendsさせる必要は無い
ディレクトリごとにルールを設定する
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
のルールだけでは、特定のディレクトリ配下のファイルにだけ別のルールを適用することができない
そのため、
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を整備して秩序と安寧を作っていきたい
参考情報
EPOMAKER EP84購入と初めてのキースイッチルブ レポ
2022年もよろしくお願い致します。(生きてます)
EPOMAKER EP84とキーボード用品をいろいろ買い漁った際のレポ記事です
EPOMAKER EP84 購入(¥8,850)
最終的に真っ白なキーボードにしたいので白色で、重めのリニア軸が欲しかったのでGateron Black軸を選びました。
2021年12月22日に注文して12月30日に届きました。
商品ページのお届け予定日では、2022年1月7~14日の間だったのでかなり早く届けてもらえました。感謝
合わせて買ったもの
- krytox 205g0 - 潤滑剤 – 遊舎工房(¥1,100)
- ルブステーションセット(¥2,600)
- 静音化リング(Oリング)(¥1,100)
- マスキングテープ(¥156)
- サージカルテープ(不織布テープ)(¥400)
開封ログ
海外からの輸送だったが箱潰れ無し
— chilitreat (@chilitreat) 2021年12月30日
— chilitreat (@chilitreat) 2021年12月30日
付属品はキープラーとスイッチプラーとケーブル(Type-C to Type-A)
— chilitreat (@chilitreat) 2021年12月30日
ゲーミングっぽく光るがダサいので使わない
— chilitreat (@chilitreat) 2021年12月30日
単色は使うかも
— chilitreat (@chilitreat) 2021年12月30日
元々スタビライザールブされていました。今回スタビライザールブもやってみようと思いましたが、結局やりませんでした。
最初からスタビライザールブされてる!? pic.twitter.com/T0ShxbWXlw
— chilitreat (@chilitreat) 2021年12月30日
サウンドテスト
改造前の買ったままの打鍵音を録音してみました。
実際に聞こえる音はMarantz MPM-2000Uで録音した音に近い印象です。
感想
- デフォルトの状態でもそこそこ満足
- 不満点を挙げるなら
- キーキャップの角がしっかり四角い
- 慣れの問題だと思うがちょっと痛い
- 個人的には若干カーブしてる方が好み
- スペースキーが若干カタつく
- スタビライザーの芯が微妙に沿っている?
今回やること
- キーキャップ交換 + 静音化リング装着
- キースイッチルブ + テープMod + スタビライザーとプレートの間にサージカルテープを貼る (この工程なんて名前なんだ...)
1. を実施した後に、2.を実施します。
1. キーキャップ交換 + 静音化リング装着
静音化リングを装着していきます pic.twitter.com/Iu5dXVkRNH
— chilitreat (@chilitreat) 2021年12月30日
元々はChoco60につけていた NP PBT Crayonを EP84に付け替えた
NP PBT Crayonに変えた。無限に可愛い pic.twitter.com/KRVBGFZC4g
— chilitreat (@chilitreat) 2022年1月2日
スタビライザーに刺さる部分へは静音リングをつけてません。
サウンドテスト
感想
- 静音リング2個で打鍵感は結構変わる
- キーの沈み込みが結構浅くなりました
- 静音スイッチのようなモニョっとした打鍵感になり若干メンブレン式っぽい
- 押下時、戻り時の高音が削られた(気がする)
- キーキャップが可愛い
- 見た目大事
2. キースイッチルブ + テープMod + スタビライザーとプレートの間にサージカルテープを貼る
初めてのルブなのでこの記事を参考にさせていただきました
やるぞぉ… pic.twitter.com/wSuFMz7ZKU
— chilitreat (@chilitreat) 2022年1月3日
稀にPCBから抜けないスイッチが1,2個あり、力任せに引き抜いたら若干欠けました...
なんやかんやで3時間くらいかかりました(84キー) pic.twitter.com/vZ39BZzHc6
— chilitreat (@chilitreat) 2022年1月3日
テープModもやってみたんだった pic.twitter.com/kDoZl4gxoh
— chilitreat (@chilitreat) 2022年1月3日
サウンドテスト
若干Macbook Proのファンの音が入ってしまいました。
感想
- 打鍵感がより重めになった
- 潤滑剤を塗りすぎた可能性?
- 静電容量無接点 + メカニカルの中間のような打鍵感になりました
- 打鍵音ピタピタからトコトコへ
- より上品な音になりました
- キーボード自体の反響音が極小に
- プラスチックケースですがテープModの効果は思った以上にある印象です
まとめ
- EPOMAKER EP84(¥8,850)
- krytox 205g0 - 潤滑剤 – 遊舎工房(¥1,100)
- ルブステーションセット(¥2,600)
- 静音化リング(Oリング)(¥1,100)
- マスキングテープ(¥156)
- サージカルテープ(不織布テープ)(¥400)
合計費用: ¥14,206
ホットスワップ可能なキーボードですし、これからキーボードを学んでいくのにちょうどいい価格帯ではないでしょうか?
今回静音化がうまくいかなかったら静音スイッチを購入しようと思っていましたが、大満足な仕上がりになったのでしばらくはこのまま運用してみます
もうすぐ Kickstarterで支援したMojo68も届きそうなので、届いたらサウンドテスト記事を書こうと思います。
Mojo68ついに発送されましたね…
— chilitreat (@chilitreat) 2021年12月31日
最後まで読んでいただいてありがとうございました。2022年もよろしくお願い致します。
2021年6月の月報
やったこと
- 初めてLaravel Package開発した
- 副業始めた
- 応用情報落ちてた
初めての経験がいっぱいあるので嬉しい
わかったこと
1. 初めてLaravel Package開発した
最近PHP案件のお声がけをいただくことがちらほらあるが、PHP全くの初心者なのでお断りすることがあり申し訳ないなと思い、 本業務でちょうど良さげなPHP案件があったのでやってみた。
最後の最後でREADME.mdに書いてある通りにビルドできないトラップを踏んで、工数を浪費する経験をした。
Contributorが退職者だらけのリポジトリを触るときは実装、テスト工数だけじゃなく調査工数なども積むようにしようと誓った。
2. 副業始めた
業務委託としてお手伝いさせていただいている。(人脈は大事)
平日も毎日1時間ぐらい働けるだろうと思っていたが、全然稼働時間取れなかった。
業務内容としては、Ruby on Rails、Nuxt.js あたりをがっつり書いている。
Railsは初めてだったので、慣れるまでは辛かったが徐々に慣れてきた。
Railsの規約がいい感じにやってくれることが多いので、あんまり本質的な理解をしないままそれらしい処理が書けてしまう。
Shrine と格闘しているが、バックグラウンド処理で動画ファイルをトランスコードする方法がわかってない
pug, scss, Vuex ORMなど初めての文化に触れることが多く刺激的な毎日で本業より楽しいまである。
初心者な自分が楽しく開発できるのは、開発以外のスケジュール調整やタスクの洗い出しを行っていただいてるからなので感謝の気持ちを忘れずに続けていきたい。
3. 応用情報落ちてた
試験会場が所沢だったので朝の移動が大変だった
秋も受けよう(次はさいたま市のどこかで受けたい
次やること
- ビルド環境のコンテナ化で属人化を防ぐ
- Effective Ruby読む
今月買ったもの
これ
デザインかっこいいけど、素材のプラスチック感が否めない。
マキネッタで作るカフェオレ、スターバックスラテの味がして最高
— chilitreat (@chilitreat) June 29, 2021
低脂肪牛乳でカフェオレ作ると美味いというツイートを見て真似した
確かに美味いけど、そこまで感動は無かった(400円ぐらい)
在宅ワークになって1週間が経った
変わったことは無数にあるので、良かったことだけを振り返る
脱東京をした
在宅ワーク発令が出てから、数日後に東京を脱した。 理由としては、東京にいる意味が無くなったからだ。 東京で働く動機は、 * 他のエンジニアからの刺激を受けならがら働く * 勉強会やイベントに参加する この辺くらいしかない。 コロナの影響で勉強会系のイベントがバタバタなくなっているので悲しい。
そんなこんなで、今は宮城から在宅ワークをエンジョイしてる。良い
通勤がなくなった
今まで職場で働くことが嫌だと思っていたが、6割くらいが通勤に対する不満だった気がする。 普段の出勤では、ピーク帯を外して通勤しているがそれでも決まった電車に乗らなきゃいけないという自分ルールが辛い
今は毎朝6時半ごろに起床して、8時から仕事を始めている。以前に比べて生活リズムが圧倒的に改善された。 普段は19時ごろに仕事を終えるが、19時は帰宅ラッシュに巻き込まれるのであと30分仕事しようみたいな謎調整いらずで仕事を終えられるのが最高。
周りに影響されにくくなった
自分のようなジュニアクラスのエンジニアにとっては、成長の機会損失とトレードオフな気がするが、、、
ストレスに感じる周りの声がなくなったのは結構心が健康になった気がする。 5分ミーティングしたいときの「ちょっといいですか?」をする機会は減った気がするが、以前が異常に多かったのかもしれない
終わりに
「明日から在宅ワークお願いします!」と経営層からお達しがあり現場は混乱しながらも無理矢理在宅になったわけだが、当初は業務にならない事もあったが1週間経つとほぼ全ての業務が在宅でも対応できるようになった。
17時に仕事を終え、晩ご飯の準備をして、散歩をして、洗濯をして、風呂に入り、11時頃にはベッドに入る生活をしている。普通のことだが幸せに感じる
在宅勤務が快適すぎて普段通りの出社をするのが無理かもしれない
転職活動が滞っている(死活問題)