Node.js — Node.js v22.18.0 (LTS)
2025-07-31, Version 22.18.0 'Jod' (LTS), @aduh95 Notable Changes Type stripping is enabled by default Node.js will be able to execute TypeScript files without additional configuration: $ echo 'const foo: string = "World"; console.log(`Hello ${foo}!`);' > file.ts $ node file.ts Hello World! There are some limitations in the supported syntax documented at https://nodejs.org/api/typescript.html#type-
TypeScriptの不要なexportを自動で削除するOSS「ts-remove-unused」を開発しました
こんにちは。メディアカンパニーに所属する鴻巣和司 (@kazushikonosu) です。普段はLINEスキマニのフロントエンドの開発をしています。業務をきっかけに、TypeScriptの不要なデッドコードを自動で削除するツール ts-remove-unused を開発し、GitHub上でOSSとして公開しました。本稿では、ts-remove-unusedが解決しようとしている問題や直近で行った大規模な変更について紹介します。 exportしていることで気づきにくい不要なコード TypeScriptを使っている場合、tsconfig.json の compilerOptions.noUnusedLocals を有効にすることで、ファイル内で参照がない不要な変数などの定義をTypeScriptコンパイラの実行時に検知することが可能です。また、ESLintなどの静的解析ツールを使い適切にルール
gql.tada に graphql-code-generator から移行した話 - Gaudiy Tech Blog
こんにちは。ファンと共に時代を進める、Web3スタートアップのGaudiyでエンジニアをしているkodai（@r34b26）です。 Gaudiyでは、以前からフロントエンド(Next.js)とGateway(Node.js)の通信においてGraphQLを使用しています。 techblog.gaudiy.com その際に、GraphQLスキーマからコードを自動生成するツールとしてGraphQL-Codegenを活用してきましたが、開発者体験やユーザー体験においていくつかの課題を抱えていたため、今回、gql.tadaに移行しました。 この記事では、課題背景から実際の移行プロセスを紹介してみるので、gql.tadaが気になっている人やGraphQLの運用に課題感のある人の参考になれば嬉しいです。 1. GaudiyとGraphQL 2. GraphQL-Codegenにまつわる課題 3. gql
Turbo 8 is dropping TypeScript
By all accounts, TypeScript has been a big success for Microsoft. I've seen loads of people sparkle with joy from dousing JavaScript with explicit types that can be checked by a compiler. But I've never been a fan. Not after giving it five minutes, not after giving it five years. So it's with great pleasure that I can announce we're dropping TypeScript from the next big release of Turbo 8. The fac
【第2回】TypeScriptもウェブも仕様や原理から楽しむ | GeeklyMedia(ギークリーメディア) | Geekly（ギークリー） IT・Web・ゲーム業界専門の人材紹介会社
2022年4月に著書『プロを目指す人のためのTypeScript入門』が発売された鈴木僚太さん(https://twitter.com/uhyo_)。QiitaやTwitterでは「うひょ（uhyo）」さんとして、TypeScriptやフロントエンドの話題を中心にウェブ技術に対する踏み込んだ解説でも知られています。 著書ではあえて触れられなかったという「TypeScriptでウェブアプリケーションをどう書くか」という観点へのヒント、なぜそれを書かなかったのか、そして仕様や原理に立ち返って自ら考えることの楽しさについて、株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出します。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務めた株式会社はてなでは「はてな
Volar: a New Beginning | The Vue Point
Most users of Volar know it as the official Vue.js VSCode extension. It started as a personal project when the official recommendation was still Vetur, and over time got adopted as the new official extension due to improved architecture and performance. As a project created to improve the quality of life for developers, we spent over two years before reaching 1.0, and have been continuously shippi
Typescript is terrible for library developers
I love typescript as an end-developer. I feel like it dramatically reduces the need to manually write automated tests. It cannot be overstated how much work is involved with writing and maintaining good automated tests so anything that can reduce its utility is a huge boon to productivity. However, as a library developer, I hate typescript. There are a lot of reasons why typescript sucks for libra
Announcing TypeScript 4.8 - TypeScript
Today we’re excited to announce the release of TypeScript 4.8! If you’re not yet familiar with TypeScript, it’s a language that builds on JavaScript and adds syntax for types. These types let you put your expectations and assumptions into your code, and those assumptions can then be checked by the TypeScript type-checker. This checking can help avoid typos, calling uninitialized values, mixing up
@ts-expect-errorを自動追加！suppress-ts-errorsの紹介
TypeScript の型チェックを厳格化したいが既存の型エラーが多すぎて、やむなく緩い型チェックにしている方へ改善の助けになりそうなツールを作ったので紹介です。 🔧 作ったもの プロジェクトのコードベースを走査して、型エラーがあるコードすべてに@ts-expect-error or @ts-ignoreのコメントを追加する suppress-ts-errors という CLI ツールを作りました。 以下の GIF のように npx 経由で簡単に利用できます。 さらに、ts、tsx だけでなくVue SFC のスクリプト部分へのコメント追加にも対応しています。 コードはこちらです。⭐ を貰えると泣いて喜びます。 なぜ作った？ 現職のプロジェクトにて型チェックを厳格化できていない（strict: trueにできていない）という状況を改善したいと思ったからです。 型チェックのルールを修正する
JS に TS のような型注釈を書ける Type Annotations プロポーザル
この記事では Type Annotations プロポーザルの概要とモチベーションについて説明する。 概要 Type Annotations プロポーザルは 2022 年の 3 月 9 日に Microsoft の TypeScript チームの Program Manager である Daniel Rosenwasser 氏のブログ記事 A Proposal For Type Syntax in JavaScript で発表され、2022 年 3 月の TC39 ミーティングで Stage 1 になった。 Type Annotations プロポーザルは JavaScript に TypeScript のような型注釈の構文を導入する。 たとえば、次のような型注釈を持つ関数宣言などが可能になる。 function hello(name: string): void { console.lo
Announcing TypeScript 4.5 - TypeScript
Today we’re excited to announce the release of TypeScript 4.5! If you’re not yet familiar with TypeScript, it’s a language that builds on JavaScript by adding statically checked types. When you use static types, you can run the TypeScript compiler to check for bugs like typos and mismatches in the shapes of your data, and get handy suggestions. These types don’t change your program, and you can re
CSS in JSとしてVanilla-Extractを選んだ話と技術選定の記録の残し方
インクリメンタルに新しい技術を取り入れる方法では、VueからReactへ段階的に移行していったという話を紹介していました。 このReactの採用を決定してから大きな論点となったのは、ReactでCSS(スタイル)をどのように書くかについてです。 Reactのスタイリング方法には、デファクトと言えるものはありません。 Styling and CSS – React CSSファイルとclassNameを使う方法、CSSファイルをimportするCSS Modules、JavaScriptでCSSを書くCSS in JSなどさまざまな方法があります。 スタイリングライブラリの選定は、表現力はそこまで大きく変わりませんが選択肢が多過ぎます。 そのため、VueやReactを選ぶといった技術選定よりも難しい部分があります。 KARTE Blocks(以下、Blocks)では、最終的にReactのスタイ
インクリメンタルに新しい技術を取り入れる方法。TypeScriptへの移行を例にしたプロセス
📝 require(moduleName) は同期処理なのに対して、import(moduleName)は非同期処理となります。 📝 tsconfig.jsonでesModuleInteropがtrueでないとdeafult importの意味合いは異なります。 この表はCommonJS ModulesとECMAScript Modulesで機能的に1対1で応するという意味ではありませんが、 大まかにはこの対応表にそってECMAScript Modulesの構文へと変換ができます。 エディターを使い手動で変換したり、次のようなツールを使ってある程度機械的な変換も可能です。 cjstoesm commonjs-to-es-module-codemod このモジュールの変換で重要なことは、できるだけCommonJS ModulesとECMAScript Modulesを混ぜないことです。
TypeScript をより安全に使うために その 2: オブジェクトの具体的な形にアクセスするのを避ける - Object.create(null)
前回はこちら. susisu.hatenablog.com 引き続き環境は以下を前提とします: TypeScript 4.4 (この記事を書いている 2021 年 11 月時点の最新版) strict: true 原則: オブジェクトの具体的な形にアクセスするのを避ける 具体例 in 演算子による型の絞り込み Object.keys の誤った使用 Object.values, Object.entries の使用 リテラルの先頭以外での object sperad 次回 原則: オブジェクトの具体的な形にアクセスするのを避ける ここで「オブジェクトの具体的な形にアクセスする」とは, 静的な型によらずに, 実行時にオブジェクトがどのようなプロパティを持っているかといった情報を取得することを指しています. ある種のリフレクションと呼んでも良いかもしれません. こういった操作には, JavaSc
どのようにTypeScriptを使うのか - uhyo/blog
現在、TypeScriptの重要性は、フロントエンド開発を中心としてますます増すばかりであります。それだけに、TypeScriptをどのように使うべきかという問題については多様な意見が見られます。 これまで筆者はTypeScriptの使い方に、特にコンパイラオプションの使い方について意見を散発的に発信してきましたが、このたび記事にまとめました。この記事では、特に次のような意見に対しての反対意見を述べます。 厳しいコンパイラオプションは型パズル愛好者のためのものであり、普通の人は細かいことを気にせず緩い設定でよい。熟練のJavaScript使いにはTypeScriptは必要ない。例え話最近はTypeScriptを補助輪に例えたりするのが流行っていますので、この記事でも例え話をしてみます。筆者の考えでは、TypeScriptというのは例えるならば料理人が使う包丁のようなものです。コンパイラオプ
Active Recordから考える次の10年を見据えた技術選定 / Architecture decision for the next 10 years at PIXTA
September 15, 2021 @ iCARE Dev Meetup #25
2021年現在Vueを選択すべきでないと思う理由
使ってわかる、Vueへの恨み、つらつらと（随時更新） コンポーネントのローカルスコープでコンポーネントを定義しようとするとJSXが必要 JSXが嫌でReactを使わないならSvelteがあり、SvelteはゼロオーバーヘッドでVueより速い React+JSXと違って、マークアップをJavaScriptの式として扱えないせいで、TypeScriptとの相性も悪い 後述するが、コンポーネントのプロパティの型をジェネリックにできないところなどは、これの例にあたる Vueの新しい機能が出て、新しい構文を必要とするたびにIDEのプラグインの対応が必要になる JSXも構文拡張だが、JS関数呼び出しのシンタックスシュガーでしかないので、関数と同じだけの表現力（汎用性）を持ち、ReactのAPI拡張のためにいちいちJSXまで拡張する必要はない JSX無しだと、マークアップ内でアクセスしたいコンポーネント
TypeScript Compiler API で40の Storybook コンポーネントを storiesOf から CSF（Component Story Format）に置換した - BASEプロダクトチームブログ
BASE株式会社 Owners Experience Frontend チームのパンダ（@Panda_Program）です。 BASE では社内用コンポーネントライブラリ「BBQ」を使ってフロントエンドの開発をしています。 BBQ は Vue2 + Storybook v5 で作成されていましたが、TypeScript Compiler API と社内のフロントエンドエンジニアの有志たちのおかげで Storybook のバージョンを最新の v6.3 にする対応が完了しました。 以前執筆した「Vue2 + Storybook v5 のコンポーネントを v6 向けに書き換える」 という記事で、Storybook v5 から v6 の書き方である Component Story Format(CSF) への変更手順を確認しました。 この記事では、TypeScript Compiler API を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TypeScript 5.9リリース！ECMAScriptの新しい仕様 `import defer` が利用可能に
tsconfig.jsonの設定を見直そう！�フロントエンド向け 2024夏
