Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜 2021/02/25(木) Node学園 35時限目の発表資料 https://nodejs.connpass.com/event/203464/ Node.js の ES Modules 対応について
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜 2021/02/25(木) Node学園 35時限目の発表資料 https://nodejs.connpass.com/event/203464/ Node.js の ES Modules 対応について
http://qiita.com/mizchi/items/3bbb3f466a3b5011b509 で紹介したモダンJSスタックの上に、flowtype を導入して型をボトムアップに追加していくアプローチを紹介します。 なぜflowtypeか、そのゴールは 流行っているライブラリのみを組み合わせて使う場合や、バックエンドとの連携において型が十分に提供される環境なら、正直、flowtypeよりtypescriptでいいと思っています。flowtypeが力を発揮する環境は、既存のJSが大量に存在する環境や、railsなどの動的な型のフレームワーク環境で、静的な定義が抽出できない環境だと思います。 よほど品質が低いライブラリを使わないかぎり、バグはほとんど自分が記述したコードによって発生します。なので、まずは「自分が書いたコードのIFを明確にし、その静的なチェックを行なう」、というのを最初の目
こないだ試したらちょうどmocha+TypeScript+power-assertが使えるようになってたのでメモる。 { "devDependencies": { "babel": "^6.0.15", "babel-polyfill": "^6.0.16", "espower-babel": "^3.3.0", "espower-typescript": "^2.0.0", "mocha": "^2.3.3", "power-assert": "^1.1.0" }, "scripts": { "test": "mocha --compilers ts:espower-typescript/guess --compilers ts:espower-babel/guess test/**/*-test.ts", "test:watch": "mocha -w --compilers ts:e
皆さんこんにちは。adingoにてFluctという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。 今回は、表題の通り、実際にプロダクトとして動いている既存のコードベースを、ES5ベースからTypeScriptに段階的に移行させた話について書こうと思います。 移行前のコードベース及び直面した課題 今年の1月頃から、アプリケーションのクライアント側の一部を、以下の構成で実際に開発しています。 言語 ECMAScript 5 主要な依存ライブラリ UI開発にReactおよびFacebook JSX syntax 統合イベントシステムとしてのRxJS テストコードのアサーションにpower-assert ビルドチェーン モジュール連結にbrowserify 環境変数に基づくビルドフラグ用途でenvify コードの解析とLintにESLint 未使用変数や未定
JSX + TypeScript の悪魔合体 ギョーム的に気持ちになったので JSX + TypeScript をはじめました。 導入にあたってチーム内への説明を兼ねたブログ。AltJSに対して ES でいいじゃん派ですが、自分の型需要に対して 現状の Flowtype が辛みしかないのでやむをえず。 動機 紆余曲折あって結局 React を使うことにした React Component には JSX with Babel を使いたい(手書きは無理だ) UI 以外のロジックを持ったモジュールは型の恩恵に預かりたい Flowtype つらい TypeScript かー UI 周りは JSX で、その他の堅いロジックは TypeScript で書けばいいのでは? 共存だ!! メリットがあるのかも不明瞭ですが、分からないからこそ試してみようという感じです。JSX と TypeScript の境界
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く