GraphQLのダイエット術 TypeScript Language Service Pluginで未使用フィールドをなくす
はじめに GraphQLは、API開発において柔軟性と効率性を提供する強力なツールです。しかし、クエリの記述が自由な分、クライアント側で不用意に多くのフィールドを要求してしまうと、パフォーマンス低下や保守性の悪化につながる可能性があります🥲 本記事では、TypeScript Language Service Pluginの1つであるGraphQLSPを活用し、GraphQLクエリの"ダイエット"、つまり未使用フィールドの削減を実現する方法を紹介します。 ※ この記事はTSKaigi Kansai 2024で共有した内容を記事にしたものです。 GraphQLの課題と対策 over fetching問題 GraphQLは、クライアントが厳密に必要とするデータのみを要求できるため、REST APIに比べてオーバーフェッチによるパフォーマンス低下を抑えることができます✊しかし、GraphQLでも
ts-blank-space
What is ts-blank-space? ts-blank-space is a fast type-stripping compiler that converts TypeScript to JavaScript. It supports a modern subset of TypeScript by erasing the types and replacing them with whitespace. That's it. It is not a type checker and does not perform any other code transformations. The underlying technique can improve build performance and simplify development. The implementation
TypeScript 5.5 で追加された正規表現構文チェックを理解する
TypeScript 5.5で、@graphemeclusterさんによって正規表現リテラルの構文チェックが導入されました🎉 この構文チェックによって、正規表現に間違いがあった場合、事前にTypeScriptがエラーを出力してくれます。 この機能について、次のことが気になったので調べてみました。 どんな構文がエラーになるか なぜ導入されたか どうやってチェックしているか JavaScriptで実行できるがTypeScriptでエラーになる構文はあるか ESLintとのカバー範囲の違い 本記事に関して、誤り等があれば指摘いただけると嬉しいです。 どんな構文がエラーになるか TypeScript 5.5では、正規表現に関するエラーメッセージが40個程度追加されています。 例えば、下記のような構文は、5.5でエラーになります。 // 存在しないフラグ var re = /a/b; // エラー
全ての道はRomeへ続くのか - これからのJavascript開発を考える
Romeとは 現代のJavascript開発には多くのツールチェーンが必要とされます。Babel,webpack,Jest,ESLint,Prettier,Typescriptなどを組み合わせて開発することが多く、さらにこれらの一部代替選としてesbuild,SWC,Viteなどのツールチェーンの選択肢が存在し、選択肢の多さやその組み合わせの複雑さに苦い思いをしたことがある方も少なくないのではないと思います。 こうした中で、新たに開発が進められているツールチェーン、Romeをご存知でしょうか？ Romeは先に挙げたように複数のツールチェーンを役割ごとに組み合わせて使うのではなく、1つのツールチェーンでこれら全ての役割を担ってしまおうという壮大な計画を持つツールチェーンです。 Romeは2020/03にFacebookより発表されました。現在は法人化され、yarnやBabelの生みの親である
大規模 Closure Tools プロジェクトに Prettier を導入するまでの道のり - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの鈴木(@__sosukesuzuki)です。 弊社のサービスである kintone では、コードのフォーマットを ESLint のみで行っているためプロジェクト内でコーディングスタイルを統一しきれていないという問題を抱えていました。 そこで opinionated なコードフォーマッター Prettier を導入し、コードベース全体でコーディングスタイルを統一するための支援をフロントエンドエキスパートチームで行いました。 2011 年にローンチされた kintone では、フロントエンドの大部分が Closure Tools を使って開発されています。Closure Tools は型の指定方法やクラスの定義方法などに独自システムを採用しており、現在の JavaScript のエコシステムや仕様と一部乖離しています。そのため、Prettier 本
OpenAPI SchemaからTypeScript Code Generatorを作ったので紹介します
他言語からTypeScriptに変換する記事を観測したので、JSONSchemaを経由してTypeScriptのコードに吐き出すライブラリを作りました。本記事のコアロジックの部分を抽出した形です。 OpenAPI TypeScript Code Generatorとの違いとして、ルートの名前空間を廃止しているので、割と自由に書ける様になってます。 https://www.npmjs.com/package/@himenon/jsonschema2ts
Semgrepを使った構文木ベースの検索と置換でコードのリファクタリングをする
Semgrepはr2cという会社/サービスが開発しているツールです。 Semgrepの特徴としてTree-sitterでコードをパースしたConcrete Syntax Tree(CST)の構文木をベースにして検索や置換ができます。 コードをCSTにパースした構文木に対して検索/置換することで、ただの文字列検索/置換に比べてミスマッチしない検索/置換ができます。 例えば、次のa.js、b.js、c.jsはそれぞれevalを使っていますが、スタイルは違いますが意味はほとんど同じです。 // a.js eval("const a = 1, b = 2; eval(a + b);"); // b.js eval('const a = 1, b = 2;\ eval(a + b);'); // c.js eval(`const a = 1, b = 2; eval(a + b);`); $ sem
Apollo LinkでGraphQLのCustom Directiveを作ろう - Qiita
これは GraphQL アドカレ2019 の記事です。 アドカレを覗いたとき、最終日だけ空いていたので予約しておいたのですが、最終日のエントリとするにはかなりニッチなネタになってしまった気がしないでもないです。 GraphQLのDirectiveとは 知っている人も多いと思いますが、GraphQLのDirectiveというのは文中に @include のように@マークをつけて注釈をつけるための機能です。 query ProfileView($renderingDetailedProfile: Boolean!){ viewer { handle # These fields will be included only if the check passes: ... @include(if: $renderingDetailedProfile) { location homepageUrl
TypeScriptの型情報を利用したCustom Transformerの現状確認 - Islands in the byte stream
TypeScriptのコンパイラ・プラグインとして振る舞いASTの操作を行えるcustom transformer (AST preprocessor) が実装されたのは TypeScript 2.4 (2017年) でした。 そのときの様子は次のエントリに非常によくまとまっています。 [TypeScript 2.4] custom transformer を利用して実行時に型情報を参照可能にする - Qiita さて、現在のTypeScript v3.3 でのTransformer APIの状況はというと、TypeScript compiler本体としては依然としてドキュメントに乗ってない水準の扱いです。特に、コンパイラAPI そのままではtransformerは型情報を利用できません。ts.TransformerFactory に渡される ts.TransformationContex
実践AST FlowからTypeScriptへの変換
About meNode.js, React, React Native, React Native for web FlowからTypeScript(TS)に移行中主要な移行対象: 12リポジトリ中身はmonorepoなので実質5-60パッケージ→ AST変換でいけないかな
TypeScriptのASTを使ってコードを解析しよう - Qiita
TypeScriptのASTを操作する方法が、GitHubのWikiに公開されていました。これを使えば,TypeScriptのコードを解析することができます。 準備 TypeScriptのインストール npm install typescriptを実行しTypeScriptを取得します。 tsconfig.jsonを設定する(Atomを利用している場合) ./node_modules/typescript/bin/typescript.d.tsをfilesGlobに追加することで、TypeScriptのASTのAPIのコード補完が可能となります(./node_modules/typescript/bin以下のd.tsファイルを追加すると、Atomが重くなりコード補完は使い物になりません) { "version": "1.4.1", "compilerOptions": { "target"
typescript-simpleの高速化と最近のTypeScript Compiler API周辺動向 - teppeis blog
ES6 compat tableのTypeScriptコードのビルド時間を300秒から2秒に短縮した話と、最近のCompiler APIの動きの紹介。 先日TypeScriptの文字列を簡単にコンパイルするtypescript-simpleというライブラリを書いた。 typescript-simpleを作った動機の1つは、ES6 compat tableのTypeScript用テストを高速化することだった。 元は300件以上あるテスト項目を、テストごとにNode.js v0.11のchild_process.execSyncでプロセスを立ち上げてTypeScriptコンパイラ (tsc) でチェックしていたので、全部テストするのに300秒ぐらいかかっていた。これをtypescript-simpleで全テストをワンプロセス内で実行したら超速化するはず！と思ったけど、300秒が200秒になるぐ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Generate React Component with TypeScript AST
外部ライブラリもインストール・型解釈できるTypeScript playgroundを作った
GitHub - phenomnomnominal/tsquery: TypeScript AST query library
GitHub - eslint/typescript-eslint-parser: An ESLint custom parser which leverages TypeScript ESTree to allow for ESLint to lint TypeScript source code.