Cybozu Frontend Monthly #57

タイトル画像

イベント概要

サイボウズフロントエンドマンスリー は、サイボウズ社内で行っているフロントエンド情報共有会「フロントエンドウィークリー」の公開版です。

その月に気になったフロントエンドの情報を、サイボウズのフロントエンドエンジニアのメンバーが共有していきます。

このイベントのハッシュタグは #サイボウズフロントエンドマンスリー です。

※フロントエンドウィークリーとは

毎週火曜の 17:00 〜 18:00 で社内向けに行っているフロントエンドの気になる記事を紹介する会です。
2016年3月15日から行われています。

ZennのPublicationにてウィークリーのまとめを投稿していますので、ぜひこちらもご覧ください。 https://zenn.dev/p/cybozu_frontend

開催日

2025年04月28日

イベントページ

https://cybozu.connpass.com/event/350880/

配信URL

https://www.youtube.com/watch?v=hidpjSg7woc

メンバー


コンテンツ

👀 Notable Articles

Node の--experimental-strip-types オプションとその影響

Node.js の v23.6.0 でデフォルトで有効化された --experimental-strip-types オプションによって、(一部制限があるものの) Node.js で直接 TypeScript を実行できるようになりました。

🔗 Node v23.6.0 (Current)

この変更により、周辺のエコシステムでもこの--experimental-strip-typesオプションへの対応が見られました。

TypeScript の --erasableSyntaxOnly オプション

TypeScript 5.8 では新しく --erasableSyntaxOnly というオプションが追加されました。

🔗 The --erasableSyntaxOnly Option

これは enumnamespace などの「型情報を削除するだけでは JS として実行できない TS 独自の構文」でエラーを出すようにするオプションです。デフォルトで有効になった Node.js の --experimental-strip-types オプションの範囲では、このような「TS 独自の構文」を含む TypeScript の実行をサポートしていません。このオプションを有効にすることで、Node.js で実行可能な TypeScript であることをチェックすることができます。

eslint の設定ファイルもライブラリ依存なしに TS で書けるように

以前から ESLint の設定ファイルは TS で書くことができましたが、内部的には設定ファイルを JS に変換するために jiti というライブラリを使用していました。

一方で --experimental-strip-types オプションが利用できる Node 環境(v 22.10.0 以上)では、ESLint の unstable_native_nodejs_ts_config フラグを有効にすると、jiti を使用せずに TypeScript の設定ファイルを直接読み込むことができるようになりました。

🔗 Node.js Native Loading of TypeScript Configuration Files (Experimental)

現在は Experimental フラグですが、Node.js の TypeScript 実行機能に合わせてデフォルトの挙動となっていきそうです。

より TypeScript First な開発へ

--experimental-strip-types オプションの導入自体が TypeScript の流行と浸透によるものであると同時に、このオプションによりさらに TypeScript First な開発は進むことが期待されます。 またその影響として周辺ツールやライブラリも一層 TypeScript の First Support を意識するようになるでしょう。

一例として、最近では ESLint が一部のコアルールを TypeScript にも対応するようにアップデートしています。

🔗 ESLint コアルールの TypeScript 対応について

このようにブラウザ以外の JS ランタイムや周辺ツールでは TypeScript の First Support 化がより進んでいます。一方で TS 独自の構文を含むコードはサポートされなかったりサポートが遅れたりすることもあるため、今後も各ランタイムやツールのサポートを確認しつつ、JS への変換容易性などを意識した TypeScript コーディングが必要となりそうです。

Next.js 15.3 で追加された Rspack のサポート(experimental)の話

Next.js 15.3 がリリースされ、Rspack や Turbopack を使ったビルドが可能になりました。 この追加により、15.3 ではビルドする際に以下の 3 つの選択が可能になりました。(アルファ版、experimental を含む)

リリースノートには、Rspack は公式プラグインではないものの、Rspack チームと連携して進めていくことが記載されています。 Next.js のビルドツールの選択肢が増えることは、利用ケースが広がりそうで良いですね。

また、Rspack に関連して、(まだ WIP の状態ですが)Rstest というリポジトリが公開されました。 https://github.com/web-infra-dev/rstest Vite と Vitest のように、ビルドツールに紐づいたテストツールがあることは、テストが導入しやすくなるので、今後が楽しみです。

社内デザインシステムを MCP サーバー化したら UI 実装が爆速になった

Ubie さんによる、社内でのデザインシステムを MCP サーバー化し、UI 実装を効率化した事例です。 Cursor Rules などを使ってコンテキスト情報としてデザインシステムを理解させようと試みても上手くいかなかったものの、これを MCP サーバーとすることで期待した通りの動作が実現できたとのことです。実際には Figma MCP も連携させることで、Figma デザインを元に自動的にデザインシステムのトークンやコンポーネントを活用した UI モックアップが構築されるようです。

ここ一ヶ月ほどですが、この Ubie さんの事例をはじめ、MCP に関する記事やニュースが非常に多く出てきました。

たとえば、Microsoft から公式で Playwright を操作するための MCP が公開され、LLM 経由で気軽にブラウザを操作可能となりました。E2E テストなど、具体的なユースケースがイメージしやすい MCP かと思います。

🔗 microsoft/playwright-mcp

Cloudflare からは、MCP サーバーをリモート利用するためのツールやガイドが公開されています。 これによって、認証がカバーできたり、プレイグラウンドで動作確認が可能となります。

🔗 Build and deploy Remote Model Context Protocol (MCP) servers to Cloudflare

日常の開発ワークフローが大きく変化する礎となる気配もあり、実際に触ってみた人も多いのではないでしょうか。 (例に漏れず、私も触って遊んでいました)

一方で、MCP は新たなセキュリティ面での懸念点でもあり、無闇に使うとリスクも大きくなりそうですね。 そのあたりに関しても非常にわかりやすくまとめて解説されている記事もあり、大変参考になりました。

🔗 MCP サーバーを利用することはセキュリティ的に安全か?

🗓 Monthly Articles

※AI によって整理・要約されています。

📖 Framework, Library

⚡️ Services

🖥 Browsers

💬 Languages

📝 Specifications

🦆 Others

フロントエンドエキスパートチームについて

https://speakerdeck.com/cybozuinsideout/frontendexpert-team