TypeScript で"moduleResolution": "Node"は使わないほうがいい
はじめにタイトルは若干煽りですが、TS 5.0 でBundlerという設定値が追加されたため、Nodeを使う場面はほぼ無くなったと思います。 今回は Node.js と TypeScript のモジュール解決の仕組みについて、moduleResolutionというオプションの観点から解説します。 この記事を書くにあたって実際に動作確認は行っていますが、もしも間違っているところがあればご指摘いただけると幸いです。 なお、 Node.js LTS v18、TypeScript v5.0 時点での情報です。 今後のバージョンアップにて変更がある可能性があります。 TL;DR"moduleResolution": "Node"は使わないほうがいい おそらく求めているものはBundler tsc をビルドツールとして使用している場合はNode16 / NodeNextがベスト Nodeを使う場合でも
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho
Tracing TypeScript Compiler
はじめにTypeScript 4.1 で新しく増えた --generateTrace という TypeScript Compiler の profile を取得するオプションについて。 TypeScript 4.1 beta でもすっ飛ばされていたネタなので、多分あまり注目されていないだろうし、 僕もたまたま PRs を眺めていたら見つけた程度だし、他の feature と比べるとかなりニッチなのだけど、個人的に面白かったのでエントリに残しておく。 なぜ僕が今回のオプションに惹かれたかとういうと、 3 ヶ月くらい前に、仕事でやっている TypeScript のプロジェクトについて「ローカルでの tsc が遅い！なんでだ！」って感じで憤ってた時期があって、 どこにボトルネックがあるか調べようと思ったことがあったのだけど、このときは深く調べることができずに挫折したという経緯があるため。 ちなみ
TypeScript 4.5でますます便利に！ better-typescript-lib v2
今日リリースされた TypeScript 4.5 Beta の新機能として、標準ライブラリの差し替えが従来よりも簡単になるというものがあります。 筆者は TypeScript の標準ライブラリからanyを排除してより安全にしたbetter-typescript-libを開発していましたが、このたび TypeScript 4.5 に対応した v2.0.0 のベータ版を用意しました（2.0.0-beta）。 この記事では better-typescript-lib の簡単な紹介に加えて、TypeScript 4.5 の機能の解説やそれによって better-typescript-lib に起こった変化を紹介します。 better-typescript-lib について better-typescript-lib は、TypeScript の標準ライブラリをより型安全にしたものです。better
named exportは有害だと考えられます
TypeScriptの話です。default exportを使うことが有害であるかのような言説に異議を唱えるためにこの記事を書きました。 あらかじめ断っておきますが、この記事はTypeScriptを使っているプロジェクトのモジュール構成に関する話です。npmに上げられているようなNode.jsパッケージ間でのimport/exportはまた別のエコシステムが関わってくる話なので、分けて考えてください。Denoにおけるimport/exportに関しては、この記事での議論がそのまま通用します。 基本的にdefault exportのみを使うべき 筆者の考えでは、named exportの方が、あなたのプロジェクトに対する害が大きいです。むしろ、「基本的にdefault exportのみを使う」ことを考えた方が良いと思います。それは以下のような理由からです。 named exportを積極的に
TypeScriptで学ぶ代数的データ型
代数的データ型とはなにか 代数的データ型とは、要素の個数の足し算と掛け算のアナロジーで語ることができる型のことを指すというふわっとしたコンセンサスがありますが、 厳密に「これが代数的データ型である」という定義はおそらくありません[1]。 また、代数的データ型はいわゆる関数型言語で実装されることが多い言語機能であり、 代数的データ型を重用するプログラミングスタイルは関数型の一派としてみなされる傾向がある[2]と思っています。 本記事では数学的な説明やアナロジーは用いず、なるべく具体的なコードを提示します。 そして、代数的データ型という言葉を「かつ」と「または」を表すことができる型として使います。 更に、「または」の型はコンパイラによって漏れなく徹底的にチェックされる必要があります。 詳細は後ほど説明します。 本記事の構成 まず、本記事における「代数的データ型」とはなにかを説明し、それをコード
TypeScript の paths はパスを解決してくれないので注意すべし！
こんにちは、江嵜です。 みなさん、 TypeScript 書いてますか？ 私は JavaScript のゆるふわ感が大好きなんですが、 やっぱりそこそこの大きさのものを開発しようと思うと 型とかあった方が安心で、TypeScript を使おうかなって気になります。 で、今回はそんな TypeScript を使う上で注意すべき小ネタ的お話を 1 点。 (文中のコードは一部全角にしているので実行される場合は注意してくださいね) TypeScript の paths って設定使ってますか？ TypeScript はコンパイルのルールを色々設定することができます。 tsconfig.json ファイルですね！ 多分一度 TypeScript を書かれた方なら触ったことがあるのではと思います。 色々な設定ができるのですが、今回はその中でも paths という設定項目について、見ていきます。 …と！そ
Prisma: Node.js & TypeScript向けの完璧なORM
本記事は、@nikolasburk氏による「The Complete ORM for Node.js & TypeScript」（2021年4月21日公開）の日本語翻訳を、著者の許可を得て掲載しているものです。今後Prismaの公式ブログの日本語翻訳の許可をいただいたので、このアカウントで継続して翻訳していきます。※画像やリンクは公式のBlogからお借りしています。 Prismaは、Node.jsとTypeScriptのための次世代ORMです。2年以上の開発期間を経て、すべてのPrismaツールが製品化の準備が整ったことをお伝えできることに興奮しています! コンテンツ オブジェクト-リレーショナルマッピングの新しいパラダイム あらゆるスタックに対応するPrisma ミッションクリティカルなアプリケーションでの運用に対応 オープンソースを超えて お手伝いできることは？ Prismaを始めよう
TypeScript 4.2 覚書
こちらの記事のまとめになります。 タプルの先頭と途中でもRest Elementsを置けるようになる タプルの先頭と途中にRestElementsを置くことができるようになります。 タプルいいですよね。僕は好きです。 // leading Rest Element let a = [...string[], boolean]; a = [true]; a = ['1', '2', false]; // middle Rest Element let b = [boolean, ...string[], number]; b = [true, 10]; b = [true, 'a', 'b', 2];
Node.js Dual Packages (CommonJS/ES Modules) に対応した npm パッケージの開発 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。フロントエンドエキスパートの平野（@shisama_）です。 フロントエンドエキスパートチームでは業務時間の 30 % の時間で技術探究を行っています。 今回は探究した技術の中から Node.js の ES Modules（以下 ESM）についてと Dual Package (CommonJS/ES Modules) に対応した npm パッケージの開発について紹介します。 ES Modules の特徴 ESM はブラウザ互換 ESM は Strict モード ESM は非同期 ESM は静的解析可能 Node.js の ESM 対応について Dual Package（CJS/ESM）に対応した npm パッケージの開発 Conditional Exports によるファイルの指定 .mjs と .cjs require など CJS 特有の機能を使う ESMから CJS ファ
TypeScript Bootcamp 2020
2020年度リクルート新人ブートキャンプ エンジニアコースの講義資料です
僕のフロントエンド技術に対するスタンス｜erukiti
僕は日頃からReact Hooks + TypeScript 最高だの言ってますけど、実のところ、それらを超えるモノが登場したら一瞬で「React Hooksなんて過去の技術だよねー、#にゃーん（社会性フィルター）」とか「TypeScript？へなにそれ？過去の言語ですよね」とかボロクソに言ってる自信があります。 補足: ボロクソにいうとは限りません。その頃に、単に手のひらクルーって返してるだけで、新しい技術を「〇〇＋□□最高！」って言ってるだけになるように、人格的に成長してるかもしれませんｗ 僕にとっては技術はただの道具にすぎません。 道具に対して必要以上の思い入れもしなければ、信仰する気持ちもありません。というより今あるクソなモノよりマシなものを求める渇望がここ数十年ずっと続いてる感じです。 そんな僕が判定するフロントエンド技術の数々を書いてみます。ブログなんでぶっちゃけテキトウで率直
TypeScript: 「電話番号型」という意味を持たせた特殊なstring型の作り方 - Qiita
この投稿では、値としては「文字列」なんだけど、単なる文字列ではなく「電話番号型」という意味を持たせた文字列型を定義し、それ使用する方法を紹介します。 TypeScriptで「電話番号型」みたいな、正規表現でバリデーションされるような型は作れるんかな？ ElmだとOpaque Typeなんてやり方があったけど。。。 用は型をexportしないで、その型の値を作る方法だけをexportすればええんかな。 — 無職やめ太郎（本名） (@Yametaro1983) April 23, 2020 ↑上のような疑問に対する答えです。 実現方針 方針としては、以下のテクニックの組み合わせです。 公称型で、「電話番号型」を定義する ユーザ定義タイプガードで、文字列型を電話番号型としてコンパイラに認識してもらう 公称型とその実装方法についての基本は下記投稿をご覧ください。 TypeScript: 異なる2つ
TypeScriptの型エラーをPR上に表示するGitHub Actionsを作成してみた
GitHub Actionsについて調べていたら、ひょんなことからworkflow commandsの存在とそれを使ってPull RequestのDiff Viewでメッセージが表示できることを知った。 (GitHub ActionsでESLintを動かした時にエラー表示してくれるアレ) 良い機会なのでTS Compiler APIの勉強も兼ねて型検査の結果をコード上に表示するためのGitHub Actionsを自作しようと思う。 できたもの Embedded content: https://github.com/marketplace/actions/typescript-error-reporter 使い方 お手持ちのGitHub Actions workflowに2行追加するだけ - name: TypeScript Error Reporter uses: andoshin11/
TypeScriptプロジェクトに独自の型定義を配置する方法 - Qiita
概要 TypeScriptの開発において、型定義ファイルが用意されてないnpmライブラリを使うのは厄介なものです。 無理やり require("...") でJSのまま読み込ませてもいいですが、ちゃんとした型定義を使用したくなるときもあります。 作成した型定義ファイルは元のnpmライブラリに取り込んでもらい package.json の types で指定してもらう方法 1 と、 DefinitelyTyped に取り込んでもらい @types/*** パッケージとしてnpm installする方法がありますが、どちらも取り込んでもらうためにはPull Requestを投げたり、ライブラリのメンテナに新しいバージョンとしてリリースしてもらったりで時間がかかってしまいます。 Pull Requestは投げつつ、それが取り込まれてリリースされるまでの間、自分のプロジェクトで作った型定義ファイル
さようなら、TypeScript enum - 株式会社カブク
フロントエンドエンジニアの今村です。TypeScriptではenumを使わずunion型を使いましょう、という話を書きます。 モチベーション 何を今さら、と思う方もいるかもしれません。 TypeScriptのunion型はenum的なものを表現可能であり、基本的にenumよりもunion型を使うべき、という意識を持っているTypeScriptプログラマーはすでに少なからずいるのではないかと思います。しかし、ではenumの使用はいかなる場合も避けるべきなのか、そうでないとしたらどのような基準でenumとunion型を使い分けるべきなのか、といった点について、広く合意の取れたガイドラインはなさそうです（少なくとも私は知りません）。この結果、コードレビューなどで少しやりづらさを感じることがあったので、白黒つけてしまいたいという気持ちからこのブログを書いています。 結論としては、enumは全面的に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - scalarhq/nominal: 🔒 The new way to do types in typescript.
Multiple connections - Blog
TypeScript の型推論をテストする - Qiita
TypeScriptの関数オーバーロードの単純な例 - Qiita
