You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに 2024年の11月に、札幌で開催された「クラメソさっぽろIT勉強会(仮) #6」という勉強会がありまして、そのライトニングトーク枠に登壇してきました。 タイトルは「minifyの効果を最大限に引き出すTypeScriptコードを書く」です。 昨今のフロントエンド開発では、TypeScriptを使ってコーディングし、それをトランスパイルしてできたJavaScriptファイルのサイズを minify によって削減するのが一般的でしょう。そうしたときに、ふと 「TypeScript の書き方を工夫したら、もっと minify が効率的に効くようになるかも?」 と思いたち、型安全性とコードの読みやすさを壊さない範囲で、どこまでファイルサイズを削れるか挑戦してみた、という話です。 今回はその LT ネタを、改めてブログ記事として共有させて頂きます。 今回のお題: Blazor SplitC
.d.tsファイルとは、TypeScriptにおいて型定義ファイルと呼ばれるファイルのことです。残念なことに、.d.tsファイルは誤った使い方をされているのを見かけることがあります。そこで、この記事では、.d.tsファイルを正しく使うために必要な知識を解説します。 .d.tsファイルとは .d.tsファイルについては、とりあえずTypeScript公式による以下の説明を読んでください(Announcing TypeScript 5.5から引用)。 Declaration files (a.k.a. .d.ts files) describe the shape of existing libraries and modules to TypeScript. This lightweight description includes the library’s type signatures
ESLint コアルールの TypeScript 対応について ESLint v9.23.0 で ESLint のコアルールの TypeScript 対応が開始しました。 その後の ESLint のアップデートでもコアルールの TS 対応が進んでいます。ESLint コアの責務を増やすような機能追加は少し意外だと感じたので、その背景について調べてみました。 背景: 従来のコアルールの拡張方法の課題 ESLint のコアルールは JavaScript を想定して書かれたものであるが、TypeScript に対してもほぼ期待通り動作するルールが多い。TypeScript は JS のほぼ上位互換な言語であるため、TypeScript 用のパーサー (@typescript-eslint/parser) が吐き出す AST もほぼ上位互換であり、パーサーさえ TS 用のものを使えば多くの ESL
「型システムの仕組み - TypeScriptで実装しながら学ぶ型とプログラミング言語」という本を書きました。 「型システムの仕組み - TypeScriptで実装しながら学ぶ型とプログラミング言語」 どんな本? 簡単な型チェッカを自作してみることで、型システムの仕組みを概観する本です。 型チェックする対象の言語はTypeScript(のサブセット言語)、型チェッカを実装するための言語もTypeScriptです。 たとえば、次のようなプログラムが型チェックできるようになります。 const add = (x: number, y: number) => { return x + y; } const a = add(1, 2); const b = a + true; 型チェッカは、それぞれの変数がどういう型を持つか管理しつつ、プログラムの各パートがどういう型になるかを判定していきます。
If you can write TypeScript, you can understand Japanese! Typed Japanese is a TypeScript type-level library that enables the expression of complete Japanese sentences through the type system. It creates a domain-specific language (DSL) based on Japanese grammar rules, allowing a subset of grammatically correct natural language to be written and verified using TypeScript's compiler. This project al
Next.js + REST APIを必要とする人のためのライブラリ 世間がRSCで盛り上がっている今でも私はREST APIを好んで使っています。OpenAPIをSwaggerUIで展開してAPI仕様書として納品できるし、保守引継ぎのためのエンジニア教育も比較的簡単です。 SwiftやKotlinでネイティブアプリ対応する場合もOpenAPIからHTTPクライアントを自動生成して使うことが多いのではないでしょうか? ゆえにNext.jsのRoute HandlersでAPIを開発したい場面がそれなりにあるのですが、公式の方法だけだと型が緩くて辛いです。回避策として全てのリクエストをHonoに投げて型を付ける記事をよく見かけますが、ファイルベースルーティングの利点が失われてしまいます。 この記事では、aspidaとfrourioの開発経験を活かして設計されたRoute Handlers特化
TypeScript 5.8で導入されるerasableSyntaxOnlyフラグを使うと、enumやnamespace、クラスのパラメータプロパティ、moduleキーワードなどの構文をエラーとして検出できます。これらの構文はNode.jsでTypeScriptを実行する際に非互換な構文であり、本フラグの導入によりNode.jsとTypeScriptの互換性が高まります。 本記事では、erasableSyntaxOnlyフラグの挙動と、なぜこのフラグが導入されたのかを解説します。 erasableSyntaxOnlyフラグの挙動 erasableSyntaxOnly とは、「削除可能な構文のみ」という意味です。削除可能な構文とは、Node.jsでTypeScriptを実行される際に削除される構文のことです。後ほど詳しく解説します。 erasableSyntaxOnlyフラグは、tsconf
はじめに 型安全性と拡張性の両立 宣言マージの活用 宣言マージとは? 宣言マージを使ってメッセージの型を拡張する 型エイリアスと Generics を使った方法との比較 宣言マージを使うことで実装と型の整合性を担保しやすくなる MUI での宣言マージの活用事例 注意点 VS Code 上の型チェックの表示が tsc の型チェックの結果と異なる場合がある ライブラリ側が空の interface のままだと困ることがある なぜ react-redux ではこのアプローチをやめたのか? まとめ interface の宣言マージを活用することで はじめに こんにちは!Element チームでフロントエンドを担当している all-user です。 Elementチームとは、テックタッチのプロダクト開発の中でも主にDOMとのインタラクション周りの開発を担当しているチームで、Shadow DOM や i
モニクル Advent Calendar 2024の12日目の記事です. はじめに モニクルの開発組織では,TypeScriptをプロダクトを作るときの最初の選択肢として採用しており,Node.jsをランタイムとした一般的なJSの技術スタックでの開発を行っています. そんな中でNode.jsのパフォーマンスに課題を感じ始め,一部のコードをRustで書き直すという作業を行いました. Node.jsに感じた課題 あらゆるサービスが稼働しているだけでお金を生み出してくれると良いのですが,残念ながら全てのサービスがお金を生み出すわけではありません.サービスを稼働させるコストがかかっているのであれば,そのコストをできる限り削減したいと思うのは組織としては一般的なことだと思います. そんな中,サービスの一部がインスタンスのメモリーリミットに引っ掛かるようになりました. 通常ウェブアプリケーションのサー
株式会社スタンバイでフロントエンドエンジニアをしている川野です。 フロントエンドエンジニアという役割を担っていますが、最近では開発者体験や開発生産性というところに興味があり、そのあたりの改善にもよく取り組んでいます。 はじめに 私たちのチームでは、Google Apps Script (GAS) を利用して、非エンジニアの人たちがシステムにスプレッドシートのデータをアップロードできる仕組みを構築しています。 GAS は手軽に開発でき、プロジェクト開始当初の小さな要求を満たすには十分なものでした。 しかし、プロジェクトが進むにつれ次第に要件が増えていき、GAS で対応するのが大変になるほど複雑になってきました。 また GAS では、型の恩恵を受けることが難しかったり、エディタのサポートが満足いくものでなかったりし、増大していく複雑さに立ち向かうのが難しくなってきました。 このような課題を解決
皆さんこんにちは。cosocafです。僕は普段C++を使っているのですが、気分転換をかねてTypeScriptでAtCoderをやってみたので備忘や後続の方のために記事を書きたいと思います。なぜTypeScriptを選んだのかといいますと、僕自身C++の次によく使う言語がこれであるためなのもあるのですが、C++、Rust、Pythonばっかのこの環境に対する反骨精神的なところもあります。 1. 準備 まずは、環境構築です。VSCodeでおこなうことを想定しています。もうコード書けるよって状態の方はとばしてください。 また、この章は記事の趣旨とずれているので簡易的な説明にとどめています。詳しい説明は別の方の記事を参考にしてください。 Nodeをインストールする Windowsの場合 ここからインストーラをダウンロードします。あとはインストーラの指示に従えば問題ありません。 Macの場合 br
「TypeScriptではじめる型システム」という記事をn月刊ラムダノートに寄稿しました。 新刊を発売しました "『n月刊ラムダノート』Vol.4 No.3(2024)発行のお知らせ https://t.co/PGppk1aRRA— lambdanote (@lambdanote) 2024年10月4日 どんな内容? TypeScriptの極小サブセットに対する型検査器を書き、それを通して型システムを体感してみよう、という内容です。 詳しく言うと、boolean型とnumber型と関数型しかないTypeScriptサブセット言語がターゲットです。 型検査器の実装言語にもTypeScript(処理系はDeno)を使います。 TypeScriptづくしの一品です。 わかる人向けに言うと、「型システム入門」という本(通称TAPL)の単純型付きラムダ計算に相当する内容をTypeScriptで説明し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く