スプシの翻訳情報を用いた型付けと段階的i18n対応のためのカスタムESLint ### 内容 ・@nuxt/i18nのt関数にパッチを当ててスプシから生成された翻訳情報で型を付ける ・段階的なi18n対応のために特定ファイルから参照されるコードのみに翻訳漏れを検証するカスタムESLint
![TypeScriptを活用したi18n対応](https://cdn-ak-scissors.b.st-hatena.com/image/square/3c3e35ea3af93f0480638489592a01ffea1c97ae/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F7c77a661a3e04f8a96ed2244204a732e%2Fslide_0.jpg%3F30459796)
これは、はてなエンジニアアドベントカレンダー2023 4日目の記事です。 3日目は id:mechairoi さんの「SQLiteでLinderaを使った日本語全文検索」でした。 blog.chairoi.me 今日のテーマは、JavaScript 向けの Linter 「ESLint」についてです。ESLint を使うと、JavaScript で書かれたコードを静的解析して、よくある間違いを検出したり、コーディングスタイルを統一できます。 通常、ESLint のルールによって報告された問題 (error や warn) は人が手で修正します。ただし、ルールが報告する問題の中には「fixable」な性質を持ったものがあります。こうした fixable な問題は、eslint --fix で自動修正できます。例えば、object-shorthand ルールによって報告された問題は、以下のよう
In ESLint v8.53.0, scheduled to be released on Friday, November 3, 2023, we will formally deprecate our formatting rules. Formatting rules are those rules that simply enforce code conventions around spacing, semicolons, string formats, etc. For a variety of reasons, which are discussed in this post, this is the right decision for ESLint going forward. However, to understand how we got here, it’s h
モチベーション そもそも TypeScript や JSX に詳しくないのでどう書くのがいいのか悩みたくない ESLint や Prettier の設定を なんとなく 設定して使ってしまっている Formatter / Linter 関連のライブラリの内容を理解せずにアップデートしてしまっている 依存関係は減らしていきたい Rust で書かれた言語向けの高速なツールが好き Rye とか Ruff とか efmt とか Biome Biome は Rust で書かれた Formatter / Linter を含むツール。本当におかしいくらい早い。 全然大きくないが、以下のソースコードに適用したときの速度。 $ pnpm run fmt > biome format --write ./src Formatted 114 file(s) in 11ms $ pnpm run lint > bi
It may seem hard to believe, but the RFC for ESLint’s new configuration system, nicknamed flat config, was first written in 2019. It took until 2022 (v8.21.0) for us to release an experimental, opt-in version of flat config. Since then, we’ve been making changes and improvements based on feedback from the community. The plan was always to allow the current configuration system, nicknamed eslintrc,
前書き ESLint は JavaScript, TypeScript のための静的検証ツールです。 ESLint を活用することで、コーディング規約やベストプラクティスを機械的に強制することによりコードレビューの手間を省き、本番環境でのエラーやパフォーマンスの悪化を抑制することができます。 TypeScript を使っているプロジェクトでは、パーサーを適切に設定すれば型情報を用いたより精密な静的検証を行うこともできます。 eslint を使う際、 eslint:recommended, plugin:@typescript-eslint/eslint-recommended などの各 eslint plugin の推奨 config のみを使って済ませたり、 eslint-config-airbnb などの config のみに頼ることも多い印象ですが、 recommended conf
これはなに コードベースに対し JSDoc の記述を必須化するための ESLint 設定手順をまとめたものです。 JSDoc を始めとする Doc コメントはコードに最も近いドキュメントであり、これがあるのと無いのとではコードベースの保守性に天と地ほどの差が生まれます。そんな JSDoc ですが、OSS ならともかく(内製・受託を問わず)商業ソフトウェア開発の現場では軽視されがちです。後からコーディング規約を定めたところで開発メンバーにドキュメントを書く習慣が備わっていなければ書き漏れが頻発するのが関の山です。 コードレビューで都度指摘するにはあまりにコストがかかるため、ESLint に委ねるのが望ましいです。 前提 フレームワークは React(or Next.js)を使っている。 TypeScript を主体としている。 ビルドスクリプトや設定ファイルは JavaScript も併用し
こんにちは、LAPRASの業務委託エンジニアのしんです。 先日弊社のプロダクト(LAPRAS と LAPRAS SCOUT)のVue3アップデートがついに完了しました🎉 中〜大規模プロダクトのVue3移行を(開発を止めずに)2回行ったことで様々な学びがありましたので、連載記事の形でVue3移行について解説していきたいと思います。 移行ビルドを用いたVue3移行は大まかに、 移行ビルドの導入前の準備 移行ビルドの導入 & 削除 のフェーズに分けることができます。 第1回目の本記事ではまず「移行ビルド導入前の準備」についてまとめていきます! 移行ビルド導入前にしたほうがいいこと 一度移行ビルドを入れてしまうと、完全に動く状態になるまでmain ブランチへマージできません。 移行ビルド導入のPRは非常に巨大になり工数もかかるため、導入前にできる作業は全て先にやっておくのが吉です(参考までに、3
ESLint の設定ファイルの形式が変わったことに際して、 ESLint は eslintrc や既存のエコシステムとの互換性を確保するために @eslint/eslintrc パッケージを公開しています。 このパッケージ内の FlatCompat クラスで eslintrc 形式の設定を flat config 内でも使えるように変換することが出来ます。 // eslint.config.js const compat = new FlatCompat({}); export default [ ...compat.extends("standard", "example"), ...compat.plugins("airbnb", "react"), ]; 🤔「FlatCompat を通せば、flat config 対応が完了するの?」 と気になったので、 npm で公開されている
あるライブラリを使っていてバグっぽい挙動に遭遇した時、ほぼ必ず当該ライブラリの Issue を検索するようにしている。加えて、見つけた Issue の subscribe ボタンを押して、https://github.com/notifications に通知がいくようにしている。バグ遭遇時以外にも、何らかの理由で Issue に到達した時にその Issue を subscribe してる。 ハマったバグの Issue を見つけた時 欲しい機能の feature reuqest の Issue を見つけた時 例: Docker for Mac の VirtioFS 対応の Issue その他面白や動向をチェックしたい Issue を見つけた時 例: TS 4.7 のリリース計画について議論している Issue 例: Jest の ESM 対応の Meta Issue 例: ESLint の
In my previous post, I explained the fundamental concepts of using the new “flat” config system. The new config system isn’t yet tied into the CLI while we do more internal testing, but we did want to give the ESLint community a chance to experiment with flat config while we work on incorporating it into the CLI. So ESLint v8.21.0 incorporates several ways to try out flat config as we work on it.
はじめに ESLint v8.21.0のリリースでこれまでとは異なるconfigシステム(flat config)が持ち込まれた。 以下の通り、新しいconfigシステムへの一歩というように言及があり、ESLintを利用する上で無視できない影響を受ける変更となりそうなので、どのようなものか確認しておきたい。 We took a big step toward ESLint’s new config system! The new FlatESLint class is now merged. Its API is not yet stable, and not all features are implemented yet, but it is accessible via the Node.js API for early testing. See RFC9 for the origi
In my previous post, I talked about how the eslintrc config system had grown to be more complex than necessary through a series of small, incremental changes. The flat config system, on the other hand, was designed from the start to be simpler in a number of ways. We took all of the learnings from the previous six years of ESLint development to come up with a holistic approach to configuration tha
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く