webpack4への簡単なマイグレーションガイド - 技術探し
トラッキング ローダー/プラグイン作者向け 変更一覧 簡単なマイグレーションガイド #0CJS(Zero-Config JS) 環境 Node4のサポートが切れました webpack-cliへの分離 ローダー/プラグインのアップデートが必要 side-effects(old: pure-module) configファイル mode loadersからrulesへ プラグイン 変更 uglifyJS extract-text-webpack-plugin その他 コード System.import() webpackInclude/webpackExcludeのサポート モジュールタイプ CJSとESMについて 前提知識 javascript/esm さいごに まだ、公式の方で作成中の段階ですので、一旦ここにまとめます。 この記事では、loader/plugin開発側の話はしません。 me
Dockerコンテナ内でのnpm installを改善してみる
開発やCIでやDockerイメージをbuildする際にnpm installすると、cacheがないため時間がかかる。 これはpackageの数が多くなると結構辛いことになるので、なんとかできないかと試してみた。 以下のような適当なpackageを使って試してみる。 { "name": "example-project", "version": "0.0.1", "description": "example", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "author": "kazu69", "license": "MIT", "dependencies": { "express": "^4.13.4", "react": "^15.0.1" }, "
Javascript unit testing tools
If you plot the commit count of each project over time it’s clear that QUnit and Jasmine are the oldest projects, and also that there is a very large amount of commits landing in the Jest repository right now (and have been for quite some time now) compared to all the other frameworks: Another interesting thing to look at is the weekly download count on npm for each framework over time; Mocha is t
なぜTypeScript推しなのか - Islands in the byte stream
KibelaのフロントエンドをES2015からTypeScriptに絶賛移行中です。 www.typescriptlang.org で、なぜ flow じゃないくてTSなのかって話です。 flow vs typescriptである理由は、どちらもJSのスーパーセットをうたう静的型付きのaltJSだからです。この時代にあえてaltJSを導入する理由としては静的型があるというのが必須で、かつ学習コストを考えるとJSのスーパーセットであるのが望ましいでしょう。 言語仕様 言語仕様の点から言うと、決定的な差はないと思っています。 メリットもだいたい同じで 生産性: エディタの補完をJSよりも賢くできるので、より少ない脳のワーキングメモリでコードを書ける 堅牢性: コンパイル時に（＝多くのケースではエディタで）typoなどの間違いを検出できるのでバグを減らせる 学習コスト: JSをベースにしており、
reducer の ノーマライゼーション - Qiita
本来は実体を配列で保持するようなケースを、次のような構成に分ける reducerが返すある状態を、全体を保持するオブジェクトと、全体の各IDを保持する配列に分ける。 全体を保持するオブジェクトのキーを指定して実体を手に入れる。まとまりをそのまま処理する場合は、全体の各IDを保持する配列にmap()を適用し、必要な実体のリストを手に入れる。 なぜ、こうするのか redux のアプローチでは、情報を管理するストアはトップレベルに一つだけある。そしてこのストアは意味のあるデータの塊ごとに reducer を作成し、必要に応じて combineReducers することで合成することができる。擬似的には
You Don't Know ES Modules
ES Modules仕様と実装の現状をひととおり紹介 Node学園 21時限目 -ES Modules Meetup- http://nodejs.connpass.com/event/34104/Read less
Flow vs TypeScript
Type Systems for JavaScript Oliver Zeigermann / @DJCordhose http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.html Most recent version including TypeScript 2.0 can be found here (might be work in progress): http://djcordhose.github.io/flow-vs-typescript/flow-typescript-2.html Part I: Introduction Why using type systems? IMHO type systems make code easier to maintain type annotations can mak
Node.jsでのJavaScriptメモリリークを発見するための簡単ガイド | POSTD
目次 初めに 極小理論 ステップ1. 問題の再現と確認 ステップ2. 最低3回のヒートダンプ採取 ステップ3. 問題の発見 ステップ4. 問題解決の確認 他のリソースへのリンク まとめ Something you might want to bookmark: Simple Guide to Finding a JavaScript Memory Leak in Node.js by @akras14 https://t.co/oRyQboa8Uw — Node.js (@nodejs) January 6, 2016 注釈：お気に入りに登録してください。 Simple Guide to Finding a JavaScript Memory Leak in Node.js （Node.jsでのJavaScriptメモリリーク発見簡単ガイド） @akras14 http://www.ale
10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 - 日々、とんは語る。
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
全てのJSライブラリはTypeScriptで書かれるべきである | POSTD
私はJavaScriptプログラマで、ライブラリをいくつか作っています。しかし最近では RxJS version 5 のために TypeScript を書いています(RxJS version 5は Angular 2 の内部で使われていますが、Angular 2もTypeScriptで書かれています)。現在私は Cycle.js をTypeScriptで書きなおしているところです。 静的型付けと動的型付けの優劣の話はやや議論を呼ぶ話題なので、その議論をすべて再発させるつもりはありません。しかし、私は、 沢山の開発者に使われることを意図した 全てのJavaScriptライブラリはTypeScriptで書かれるべきだと信じています。これはアプリケーションやウェブサイトをTypeScriptで書くということの話ではなく、ライブラリに関する話です、ライブラリはTypeScriptで書かれるべきで、
Node.js ES2015/ES6, ES2016 and ES2017 support
"use strict"; function f(n){ if (n <= 0) { return "foo"; } return g(n - 1); } function g(n){ if (n <= 0) { return "bar"; } return f(n - 1); } return f(1e6) === "foo" && f(1e6+1) === "bar";
ES6 in Practice
Firefox Developer Conference 2015の講演資料 http://www.mozilla.jp/events/devcon/2015/tokyo/ ES6 Modulesの現状確認がメインです。Read less
JavaScriptは如何にしてAsync/Awaitを獲得したのか: がおさんち 技術部屋
JavaScriptを記述する上で、避けて通れないのが非同期処理。 人類は、長い年月、この非同期的な処理を「如何にして書きやすく、読みやすく記述するか」について探求してきました。 要するに†闇†の塊なのですね。（闇に飲まれよ！！！！） この物語は、そんな†闇†の存在だった非同期処理を、人類がどのように苦しみ、そしてどのように解決していったかを書いていくポエムである。 補足：厳密には、JSはシングルスレッドで動くため、非同期処理は存在しない！と言ってしまえばそこまでなのですが、今回はsetTimeoutやajax通信、onloadイベント登録など、見かけ上、非同期的な挙動を示すものすべてを対象に話していきます。 第一章 ～人類はsetTimeoutを採用しました～ 古代のJavaScriptで、以下のような処理をしたい場合、どうしていただろうか。 「ブラウザ更新直後に『a』を表示し、その2秒
News, Views, and How-Tos from NGINX, Inc. | NGINX
F5 Sites DevCentral Connect & learn in our hosted community F5 Labs The latest threat intel and research to help protect your apps MyF5 Your key to everything F5, including support, registration keys, and subscriptions Partner Central Research and support for partners LearnF5 Guidance, insights, and how to use F5 products Contact F5 Contact F5 Sales Talk to an F5 sales representative Contact F5 Su
Rx.js, Immutable.js について - mizchi's blog
自分はImmutable.jsとRxをなぜ採用しなかったか、自分の考えを整理するために書き出してみる。 僕の理解が及んでいない無知のゆえのアレもあると思うので間違っていたら罵倒ブコメお願いします。 Immutalbe(.js) 扱う対象をイミュータブルにするのはたぶん間違いなく正しい。正しいが、現時点のエコシステムにおいてその必要性を示せてない。具体的に言うと、Immutable.jsの110kbのオーバーヘッドの配信負荷、読み込み負荷、開発者の学習コストを支払ったとき、それに見合う価値を提示できているのか？にまだ疑問が残る。 PureなJSでも、ただ単に目的のデータを作るだけなら、ほとんどのケースで組み込みのarray.mapとObject.assign(またはそのポリフィル)で代用できる。(勿論生成したオブジェクトに副作用を加えないことが前提になるが) あと型がない環境でImmutab
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A minimum custom renderer implementation using ReactFiber
Moving from JavaScript to TypeScript at Slack
Loading...
Promisees · Courtesy of ponyfoo.com
Effective ES6
