TypeScript/JavaScriptの言語思想的にはtry/catchを使ってerror handlingをするのが普通
TypeScript/JavaScriptの言語思想的にはtry/catchを使ってerror handlingをするのが普通
こんにちは。N 予備校 Webフロントエンド開発チームの中村です。 TypeScriptを使用しているプロジェクトでコンパイラの設定を変更したら既存のソースコードがコンパイルに通らなくなった……という経験はないでしょうか。 先日あるリポジトリでnoUncheckedIndexedAccessというコンパイラオプション(TypeScript4.1以降で使用可能)を有効化した1ところ、既存ソースコードの200箇所以上がコンパイルエラーになりました。これを全て手作業で直すのは大変ですし、その間にも直さないといけないコードは増えていくかもしれません。 そこでTypeScriptのCompiler APIを使用し、コンパイラから得られるコンパイル時のエラー情報を利用して@ts-expect-error2を挿入するスクリプトを作成しました。その過程と結果を書きましたので、次のような方々の参考になれば幸
こんにちは、21 卒エンジニアの id:d-kimuson です。 モバイルファクトリーでは、最近のプロダクトではフロントエンドに TypeScript を採用していますが、僕がアサインされているプロダクトは歴史が長く JavaScript で書かれていて、今回 TypeScript へのリプレースを行いました。 既存プロダクトの TS リプレースではしっかり型付けすることは難しいので、型チェックオプションを緩くしてリプレースすることが多いと思います。しかし、既存コードからリプレース後のコードまで全て型安全性が担保できなくなってしまうので、後からの strict 化は非常に大変になってしまいます。 今回のリプレースでは、型チェックオプションは緩くしない代わりに @ts-nocheck や @ts-expect-error を使用することで、段階的に型安全性を高めやすい形でリプレースを行いま
Stop catching errors in TypeScript; Use the Either type to make your code predictable In some languages such as Java, methods or functions can provide type information about the Exceptions or Errors they may throw. However in TypeScript, it is not possible to know what Errors a function may throw. In fact, a function could throw any value, even a string, number, object, etc. This is why TypeScript
この記事の公開時点ではTypeScript 4.5のBetaが出たばかりといったところですが、TypeScriptのリポジトリでは早くもTypeScript 4.6をターゲットにした改善が考えられています。おそらく、大きめの新機能であるためすでにBetaが出ている4.5は避けたのでしょう。この記事ではそのうちの一つである、タグ付きユニオンに対するさらなる進化をご紹介します。PRでいうと次のものです。 また、この変更によって、TypeScript 4.4, 4.5, 4.6と3連続でタグ付きユニオンが進化することになります。これらについてこの記事で紹介します。 TypeScriptにおけるタグ付きユニオン せっかくなので、この記事ではTypeScriptでのタグ付きユニオンについて基本的なことも解説します。タグ付きユニオンは、他にも「直和型」など色々な呼び名がありますが、英語圏のTypeSc
Next.js には組み込みのエラーフォールバック機構が存在します。pages/404.tsxとpages/500.tsx、Unhandled Error を捉えるpages/_error.tsxが組み込みフォールバックです。https://nextjs.org/docs/advanced-features/custom-error-page 実アプリケーションにおいてはこれだけでは不十分なケースが多く、意図的なもの・そうでないものをハンドリングしログ収集に繋げるなど、きちんとエラー設計をしたいところです。 TypeScript 4.4 で try catch の推論が変更になった 話が少しそれますが、TypeScript 4.4 で try catch 文の catch 引数errの推論がanyからunknownに変更になりました。この変更はuseUnknownInCatchVariab
この記事について webpack の設定ファイルであるwebpack.config.jsは、TypeScript で書いて Node.js 上で実行できます。しかし、本来であれば TypeScript のソースコードは Node.js では実行できないはずです。 この事が気になった私は、今回その仕組みを調べてみたので、この場を借りてその調査結果を共有したいと思います 💪 参照 記事の概要 概要のみ知りたい人に向けて、以下にこの記事で解説する内容をまとめておきます 👇 webpack-cli では、 rechoir を使って TypeScript を require() できるようにしているよ rechoir は、 ts-node などを使って require.extensions を拡張しているよ ちなみに、 require.extensions は非推奨だよ webpack-cli
(※ この記事は API およびそこから導かれる設計のしやすさ観点での比較をしています。実際にキャッシュが有効に効いたか、などについてはまた別の機会に )
I recently decided to switch the engine of Boardgame Lab from TypeScript to Rust. The application itself is an SPA written in Svelte. I only switched the logic that updates the game state to Rust. Here is a summary of my experience with the transition: Isomorphic ArchitectureOne of the advantages of using JavaScript or TypeScript is that you can run the same code on both client and server. For Boa
やりたいこと 巨大なコードベースに対して、 .js をとりあえず .ts に書き換えてしまいたい。 だが、素朴な拡張子の書き換えで型違反が出ると jest やその他ツールが止まりはじめて面倒。 なので、エラー行には // @ts-expect-error を自動で付与しながら書き換えたい。@ts-ignore ではなく、@ts-expect-error なのは、型エラーを修正した際に、それが伝搬するようにするため。 方法 ファイルの拡張子を .js から .ts に書き換える typescript service 経由で型を検査し、エラー行を集める エラーが出た行に // @ts-expect-error を付与する コード 書き捨てなので汚いです import * as ts from "typescript"; import { uniq } from "lodash"; import
原文(投稿日:2020/05/19)へのリンク 新ライブラリのHegelは、JavaScriptで高度な静的型チェックを実現しようという試みだ。強い型推測と完全な型システムを提供するという。現在はまだアルファ版だが、専用のオンライン・プレイグラウンドで動作を確かめることができる。 Hegelは型アノテーションを備えたJavaScript用の型チェッカである。TypeScriptの場合のように、新たなプログラム言語構造を学ぶ必要はないが、アノテーション記法についての学習は必要だ。Hegelは強い、完全な型システム(Sound File System)を使うことで、実行時の型エラーを防止する。 const numbers: Array<number> = []; // HegelError: Type "Array<number>" is incompatible with type "Arr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く