今Reactを使うならピュアなCSSをサポートするUIフレームワークやライブラリを選定するのがマルそうと思った話
最近個人開発でNext.jsの環境を立ち上げた際に、スタイリングをどうやってやろうかなと迷ったので初心に帰って最近のスタイリングについて調べ直してみました。結構面白かったので、記事にまとめることにしたので、よかったら読んでみてください。 本記事では以下に触れます。 React界隈におけるスタイリング方法の歴史的変遷 なぜタイトル通りピュアなCSSをサポートする機構が良いと感じたか おすすめのスタイリング機構 ざっと振り返るReactのスタイリング方法の歴史的変遷 私が最終的にピュアCSSを推したいと思った理由をお話する前に、爆速で変わり続けるReactとともに、スタイリングはどう変遷していったのかをざっとまとめたいと思います。 （こういうのって、歴史と組み合わせて理解すると、結構深まりますよねと思っているのは私だけでしょうか…、いえそんなことはないはず😊） 大昔: CSS Modules
ESLint の Flat Config を書く時に読んでほしい記事 (2024-08版) - Object.create(null)
2025-03-30 追記: 改訂版を書きました. susisu.hatenablog.com ESLint v9 から Flat Config がデフォルトの設定ファイルの形式となり, 徐々に対応しているプラグインも増えて移行が進みつつありますが, 実際に移行したプロジェクトを見ているとしばしば勘違いなどから誤った設定をしている事例を目にします. ということで, Flat Config を書くにあたっていくつか知っておいて欲しいことや, よく見かけるミスをまとめてみました. この記事では網羅的な説明はしませんので, ESLint や typescript-eslint の公式ドキュメントを前提として, 副読本的に参照してください. Getting Started with ESLint - ESLint - Pluggable JavaScript Linter Getting Star
仕組みと嬉しさから理解するeslint FlatConfig対応
重い腰を上げて FlatConfig 対応をした ESLint が新しい設定形式として FlatConfig を導入してから随分と経ち、最新バージョンの v9 では FlatConfig がデフォルトになりました。一方で利用者の多い plugin でもなかなか対応が進まず、周りでは思ったよりも FlatConfig への移行が進んでいない印象を受けます。 とはいえ次のバージョンである v10 では FlatConfig しかサポートしないことが予定されており、今まで移行を見送ってきた方も「さすがにそろそろ移行するか...」と思っているのではないでしょうか。自身の所属チームで管理している ESLint の rule セット : @cybozu/eslint-config でも遅ればせながら FlatConfig 対応を進めています。（現在はアルファ版で提供中です） そんな @cybozu/e
TypeScript/JavaScriptの不要なコードを削除するツール「Knip」の紹介 - ベースマキナ エンジニアブログ
こんにちは、taroです！ 今回は、ベースマキナのTypeScriptのプロジェクトで不要なコードの検知・削除で使用しているKnipについて紹介します。 Knip とは Knipは、TypeScript/JavaScriptのコードベースの不要なコードを検出するCLIツールです。 以下が検出できる不要なコードの例です。 package.jsonのdependencies/devDependenciesの中で使われていないpackage exportされているがどこからもimportされていない変数、関数、型など 使用していないファイル その他、検出できる内容の一覧はこちらで確認できます。 またExperimentalな機能（2024年7月現在）として不要なコードの自動削除も可能です。 ちなみにTypeScript/JavaScriptの不要なコードの検出するツールではts-pruneも知ら
Quokka - JavaScript and TypeScript playground in your editor
Quokka.js runs JavaScript and TypeScript with instant feedback, displaying runtime values in your editor as you type. Quokka makes exploring, learning, and testing JavaScript / TypeScript blazingly fast. By default no config is required, simply open a new Quokka file and start experimenting. Focus on writing code instead of writing bespoke config files just to try a simple idea or learn a new lang
JavaScript/TypeScript の Lint ツールを XO で統一した - ドクターズプライム Official Blog
@1000ch (id:hc0001) です。掲題の通り、少し前にドクターズプライムの Frontend プロジェクトで使う lint ツールとして ESLint ではなく XO を使っていく方針に切り替えました。最近その振り返りを行ったので、その備忘録として文字に起こします。 github.com 経緯と課題 これまでは Create React App に付属する ESLint に加えてルールを少しカスタマイズして、それをいくつかのプロジェクトで使っていました。これにはいくつかの課題が存在していました。 ESLint およびその周辺プラグインの依存関係を含めたバージョンアップをケアし続ける必要がある renovate や dependabot などを用いて（半）自動化できるものの、依存の数や大きさに応じて依然としてコストが高い ESLint のルールを中長期的にメンテナンスする必要があ
最近の ESLint とかの構成2021
みんな好きな構成を好きなように入れれば良いと思ってるけど、自分が最近やってるやつを雑に紹介する。 シンプルなTypeScriptのプロジェクトを想定している。 npm install --save-dev eslint prettier typescript eslint-config-prettier @typescript-eslint/parser @typescript-eslint/eslint-plugin npm-run-all
Typicode's blog - Husky 5
I’m happy to announce the release of husky 5 🎉 🐺 woof! During the past years, husky has grown in complexity. With this version, I wanted to go back to something simpler, more flexible and closer to the metal. You can use husky 5 in your Open Source projects today. Thanks for your support and feedback. I hope you’ll enjoy this release <3 https://github.com/typicode/husky Faster and smallerHusky 5
Prettier と ESLint の組み合わせの公式推奨が変わり plugin が不要になった
前に書いた ESLint と Prettier の共存設定とその根拠について が公式推奨が変わったことにより一部間違った情報になっているのでその訂正記事です。 該当記事に書いた内容は Prettier と ESLint の関係を読み解く上で役立つ情報だと思うので、警告とこのページへのリンクを書いた上でそのまま残しておきます。 (追記) この記事の内容も間違った内容を書いていました。なので一度大幅な訂正をしています。prettier-eslint も推奨ではありません。 変更点の要約 Prettier と ESLint の組み合わせについて公式 の推奨方法が変わりました。 きっといつかこの情報も古くなるので直リンクではなく、ドキュメントの GitHub のリンクを貼っておきます。 ドキュメント自体のリンクはこちらです。 新しいドキュメントを要約すると、 Linter と Formatter
ESLint と Prettier の共存設定とその根拠について
注意 この記事は 2020 年 09 月 24 日現在、古い情報となりました。 eslint-plugin-prettier の利用は非推奨であると公式がアナウンスを出しています。 そのことについては Prettier と ESLint の組み合わせの公式推奨が変わった にてまとめましたので、こちらもご覧ください。 また eslint-plugin-prettier は公式推奨ではなくなりましたが、それは Editor などの外部環境の進化によるものでこのプラグイン自体に何か問題が起きたわけではありません。 そして eslint-plugin-prettier を利用した設定方法、特に eslint-plugin-prettier と eslint-config-prettier が何を解決していたかを知らないと、prettier-eslint が何をどう解決したかを理解できないはずなので
webpackの次のバージョンで入るassetModulesの紹介 - 技術探し
この機能が導入されることにより、{raw/file/url}-loader が不要となります。 webpack@4 でも使えますが、まだ実験的フェーズです。 Documentation Asset Modules | webpack webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.
@typescript-eslint ことはじめ - teppeis blog
追記: 2019/05/01 最近の@typescript-eslint/eslint-plugin, Prettierのアップデートによって、正式にTypeScript 3.4対応されました。一通り普通に動いてる感じ。 これまで自分で使っていて問題になったのがパフォーマンス。ESLint単体やTSLintに比べて、プロジェクトによるだろうけど2倍以上遅い。体感で結構辛い。 Poor performance on some projects · Issue #389 · typescript-eslint/typescript-eslint これはTypeScriptのパーサーを通す部分の構造上の問題が原因なので、簡単には直せなそうな気配。 とりあえず、個人的には型を必要とするルールにそこまでの価値を感じていないので、該当ルールを無効にしてparserOptions > projectを削
愚直にESLintを導入した話 | メルカリエンジニアリング
こんにちは、エンジニアの@sota1235です。 タイトルの通り、今回は愚直に改善をした話をします。 メルカリのJavaScript メルカリにおけるJavaScriptの活用場面は以下のようなものがあります。 メルカリWeb アプリ内Webview 社内ツール React Native Node.js製のbotやGoogle App Scripts etc… いずれもサービスにとって重要なものであり、サーバサイドエンジニアであってもJavaScriptに触る機会は少なくありません。 かくいう私も普段はサーバサイドエンジニアですが、JavaScriptコードを書いたりレビューする場面が多くあります。 そんな中でWebチームにおいて、JavaScript開発でいくつか問題がありました。 課題その1: JavaScriptのレビューコスト問題 1つ目の課題としてJavaScriptのコードをレ
2018/07/12 に発生したセキュリティ インシデント (eslint-scope@3.7.2) について - Qiita
2018 年 7 月 12 日に、ESLint 開発チームが管理する npm パッケージに悪意あるコードが挿入されるセキュリティ インシデントがありました。 ESLint からのアナウンス: https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes npm からのアナウンス: https://status.npmjs.org/incidents/dn7c1fgrr7ng 以下の場合に npm install を実行したユーザーの npm アカウントへのログイン情報 (アクセストークン) が盗まれた恐れがあります (盗まれたアクセストークンはすでに無効化されています)。 日本時間の 18:49 から 19:25 の約 1 時間のあいだに npm install を実行し、eslint-config-e
Workboxで始める Service Worker
The document describes how to configure a service worker to cache assets and network requests to improve performance for a web application. It shows code for registering a service worker, precaching assets using Workbox, transforming precached URLs to include cache-busting query strings, and configuring runtime caching for API requests using a network-first strategy with a 30-day cache expiration.
webpack初級者から中級者にステップアップするために理解しておきたいプラグインまとめ - Qiita
はじめに Rails5系から、webpackerが導入され注目を集めるwebpackですが、名前聞いたことあるし、いっちょ試してみっかとHello, World!的に触って見た人は多いのではないでしょうか？ 僕も流行りに乗っかって、gulp、Browserify、Reactifyで行っていたReactのjsxのコンパイルを、webpackとbabelを用いて行うように変更したのですが、まあ、設定ファイルを作成するのが難しいわけですよ。 実際は、entryとoutputと必要ならloaderを定義するだけである程度の事はできるので、特定の目的を達成するだけなら凄くシンプルなので分かりやすいんです。関連するプラグイン豊富ですし、やれることも多いですし。 なので、厳密に言うと、関連するプラグインや設定が豊富が故に自分たちのプロダクトに合った設定ファイルを作成するのが難しいんですよね。 その設定フ
webpack -> FuseBox 移行メモ - Qiita
webpackを使っていたプロジェクトをFuseBoxに移行してみました。 バンドル時間が超速くなり、バンドルファイルサイズが超小さくなりました。 webpack FuseBox package.json package.jsonの比較です。 "devDependencies": { "babel-cli": "^6.26.0", "babel-core": "^6.23.1", "babel-eslint": "^8.0.0", "babel-loader": "^7.1.2", "babel-preset-es2015": "^6.22.0", "babel-preset-flow": "^6.23.0", "babel-preset-react": "^6.23.0", "css-loader": "^0.28.7", "eslint": "^4.6.1", "eslint-load
App Shell モデルの素振り（前編）webpack と Workbox を利用した構築
App Shell モデルという設計パターン App Shell モデルは、共通のガワ部分を構成する HTML、CSS、JavaScript をシェルと定義し、その中に入る動的なコンテンツ部分と構造的に分離して扱えるように設計されます。 アプリケーション シェル（App Shell）アーキテクチャは、ネイティブ アプリのように瞬時に、そして確実にユーザーの画面に読み込める Progressive Web App を構築する方法の 1 つです。 アプリの「シェル」とは、ユーザー インターフェースが機能するために必要な最小限の HTML、CSS、JavaScript です。これらをオフラインで使用できるようにキャッシュしておくことで、ユーザーが同じページに再アクセスした際に、瞬時に高いパフォーマンス が発揮されます。つまり App Shell は、ユーザーがアクセスするたびにネットワークからす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自分流の静的ウェブ開発環境 2018年版 - Qiita
ESLint 設定を Glob ベースでがっつり書き直した - Qiita
