Get 73% off the Angular Master bundle See the bundle then add to cart and your discount is applied.
TSLint v4 TSLintは、TypeScript専用のlinterでしたが、TSLint 4.0から、JavaScriptのlintができるようになりました とはいえ、ルールの数などでは、ESLintなどのJavaScript専用Linterにはかないません(ESLintにはTypeScript ESLint Parserという実験実装があるので、JavaScript専用というと怒られてしまうかもしれませんが )。そのため、TSLintでJavaScriptのLintが役立つのは、TypeScriptプロジェクトの中に、TSに対応していないごく一部のJavaScriptファイルがある場合だけです(e.g. gulpのソースのみJSで記述している場合など)。効果は局所的ですが、一部のファイルのlintのためだけに、TSLintとESLintを併用しているプロジェクトには役立つはずです
const compile = require('types-assert/compiler').compile; const assert = require('types-assert/assert').assert; // tsファイルをtypes-assertのオブジェクトに変換 const type = compile('type.ts'); const obj1 = { stringProp: "hoge", numProp: 2 }; // 型が正しい場合はスルー assert(obj1, type.Interface1); const obj2 = { stringProp: "hoge", numProp: "2" }; // 型がおかしいのでError assert(obj2, type.Interface1);
(d932ad7) chore(browser): rename protractor to browser and add a protractor namespace (#3214) added wrapDriver method from the browser.ts and ExpectedConditions to the protractor namespace imported selenium webdriver ActionSequence, Key, promise, Command, and CommandName to the protractor namespace Selenium Webdriver has deprecated getInnerHtml and getOuterHtml. You'll need to update your tests to
TypeScript の Promise の型 だと、型パラメータが Promise#then 側しかなくて、 Promise#catch 側の型が any になってしまって不便だ。 もし、catch 側の型についても型引数で指定できたなら、より安全なプログラミングができる。 そこで、catch 側の型を指定していない理由について考察してみた。 理想 const promise: IdealPromise<T, E> = getPromise(); promise .then((x) => { /* x は T 型 */ }); promise .catch((e) => { /* e は E 型 */ }); 実際 const promise: Promise<T> = getPromise(); promise .then((x) => { /* x は T 型 */ }); prom
はじめに DIコンテナ自体は特に目新しい技術ではありません。JavaScript界隈ではAngularJS 1.xやRequireJS(AMD)等はそれ自体がDIの仕組みを内包したライブラリです。 しかし、これらのDIは若干無理やりな実装方法を取っていた感があります12。これはJavaScriptでメタデータやAOPを適切に扱う機能が不足していたことが背景にあると考えているのですが、ここ1, 2年で言語側の状況も変化してきています。 具体的にはTypeScript 1.5からDecoratorsがサポートされたり、ES 2015にてリフレクションの仕様が追加されたりと、よりスマートなDIコンテナを実装するための基盤が整いつつあります。 そこで今日はInversifyJSという軽量JavaScript DIコンテナについて触れるとともに、最新のDI事情を見ていきたいと思います。 Invers
The type system is like training wheels. It keeps you from falling, at the price of slowing you down and limiting flexibility.This article is now available in Japanese and Chinese. Last summer we had to convert a huge code base (18,000+ lines of code) from JavaScript to TypeScript. I learned a lot about the strengths and weaknesses of each, and when it makes sense to use one over the other. When i
With things like TypeScript and Flow becoming more popular, I'd really like to find a way to incorporate type annotations into ESTree in some sort of common way so we can start creating tooling around it. In particular, we're getting more requests in ESLint to be able to write rules around type annotations, but without having this is information in a predictable place, it's really hard to do that
2015 - 12 - 18 あれから一年、あの TypeScript プロジェクトは今 はてな でアプリケーションエンジニアをしている id:t_kyt です。この記事は はてなデベロッパーアドベントカレンダーを始めます - Hatena Developer Blog の18日目です。 昨日は id:wtatsuru による「 はてなで新しくWebサービスを作るときのインフラの作り方 - Hatena Developer Blog 」でした。 今回は「TypeScript で実現する MVP アーキテクチャパターン 」のその後、1年近く TypeScriptプロジェクトを開発運営してきた話をしたいと思います。 developer.hatenastaff.com 「TypeScript で実現する MVP アーキテクチャパターン 」の要約とこの記事の概要 この記事を読む前に前述した記事を読
皆さんこんにちは。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 の境界
Dojo 2 Vision A Quick Dojo 1.x history The Dojo Toolkit began in 2004 by a group of like-minded JavaScript engineers that were tired of reinventing the wheel and hacking around browser inconsistencies. The mission of the Dojo Toolkit has been to: Provide consistent and easy to use features and APIs that allow developers to create maintainable web apps faster and easier without having to worry abou
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く