小さなEventEmitterライブラリ - eventmitを書いた
EventEmitterのようにPub/Subを行うeventmitという小さなライブラリを書きました。 azu/eventmit: Simple EventEmitter. A single event object per an event. eventmitは、TypeScriptで書かれています。 また、Node.jsのEventEmitterなどとは違って、イベント一つに対してeventmitのオブジェクトを一つ作成して使います。 import { eventmit } from "eventmit"; const event = eventmit<{ key: string }>(); // Register handler event.on((value) => { console.log(1, value); }); event.on((value) => { consol
シンプルだけどシッカリ働く最新のECMAScript開発環境 - Qiita
どうも、最近スマホゲー界隈からコンバートしてきた新米フロントエンド戦士です。 数年前はブラウザゲー界隈にいたんですが…完全に浦島太郎状態です。 ここ数ヶ月で色々学ばせてもらいつつ、自分なりのNode開発環境が整ったので公開しちゃいます。 完成した環境はこちらのv1.0（masterの最新はこちらでクロスプラットフォーム対応を行ったものになります） 2018/8/28 追記 本日 Babel7がリリースされました！ それに伴いパッケージ名が変更されていました。 babel-core -> @babel/core babel-preset-env -> @babel/preset-env また babel-preset-env2.0でbabel-polyfillは不要になるらしい の件が実験的機能として導入され、以下のようにuseBuiltIns:usageと設定すると必要に応じて自動でpol
JavaScript モジュールの現状 | POSTD
(注：2017/07/19、いただいたフィードバックを元に翻訳を修正いたしました。) ESM、CJS、UMD、AMD — どれを使うべき？ 最近、 Twitter では、 ESモジュール の現状、特に、 *.mjs をファイル拡張子として導入すると決めた Node.js の現状について大騒ぎになっています。この話題は複雑で、かなりの労力を費やしてそれに専念しないと議論について行けないので、 皆が恐れと不安を抱く のも無理はありません。 古き恐れ フロントエンド開発者なら、 JavaScriptの依存関係の管理に悩まされた日々 を憶えている人も多いでしょう。あの頃は、ライブラリをベンダーフォルダにコピー&ペーストし、グローバル変数に依存し、あらゆる物を正しい順序でconcatしようとしてもネームスペースの問題に対処する必要がありました。 何年もかかって、私たちは共通モジュール形式と中央集権
"デバッグしてください", "パフォーマンスチューニングしてもらってもいいですか?" とJavaScriptが難読化された状態のページのURLを渡してくる人に、伝えなきゃならない事がある - latest log
webpackを使ったサイト、極端にデバッグしずらい (外部ライブラリが eval(文字列) の形で埋め込まれる)ので、はっきり言って大キライだったりする— コラーゲンたっぷりさん (@uupaa) 2017年4月19日 見知らぬコードが minifyされ、さらに eval されているのをデバッグしろとか、暴力にも等しい要求なんだよね。そりゃキライになるよ— コラーゲンたっぷりさん (@uupaa) 2017年4月19日 「環境Aの言語Bで書かれたコードを言語Fに変換した、環境C/D/Eで動くと思うのでデバッグしろ」というのも極端にデバッグしづらいという理由から避けるようにしている。 デバッガビリティに問題がある環境は、心がすり減るのでイヤ(時給1万円なら頑張る— コラーゲンたっぷりさん (@uupaa) 2017年4月19日 js minifyあるある A「パフォーマンスに問題があるので
Demystifying webpack2 tree shaking - from scratch
webpack2 に最近移行しました。 その時の知見とせっかくなので tree shaking が実際に中でやってることを追ってみたので紹介。 webpack2 移行時の注意 基本的にはほぼここに書いてあるとおり。 Migrating from v1 to v2 かいつまんで説明すると、configファイルの書き方がガラッと変わって、 module.loaders が module.rules になったり、 resolve.root がなくなって resolve.modules に変わったり。この辺の書き換えは割りとすんなりいくはず。 辛いのはpostcss周りのオプションの渡し方辺り。これまではconfigのrootにpostcssプロパティを用意してそこに記述できたが、その記述はできなくなり、 webpack.LoaderOptionsPlugin 経由で渡すか postcss.con
JavaScriptを劇的に教えやすくするWebサーバ作りました - Qiita
近年、JavaScriptでコードを書こうとすると、お膳立て7割、コード書き3割みたいな事態がざらにあります。「お膳立て」の例としては、Gulp, Babel, Sass, PostCSS, WebPack, Rollup, Browserifyほか数限りなく。 たしかに、一旦フロントエンド開発に慣れてしまえば、お膳立てにかける時間は短縮することが可能です。でも、これを初学者に強いるのはツラすぎる...! 覚える方はともかく、 教える側がツライ。 今回、未来なJavaScriptやCSSの文法で書いても、よしなにとりなしてくれるWebサーバ「Felt」を作ったので、ご査収ください。 (2016/7/19 関連ツールとの比較を追記しました) GitHub: https://github.com/cognitom/felt npm: https://www.npmjs.com/package/
react-storybookを用いたReactコンポーネント開発 - Hatena Developer Blog
こんにちは！Webアプリケーションエンジニアの id:amagitakayosi です。 今日はReactコンポーネントを手軽に開発するためのツールを紹介します。 前回のあらすじ react-storybookとは 導入してみる 初期設定 storyを作成する 起動 イベントを監視する Hot Module Reloadingの仕組み メリットとデメリット リアルタイム確認できる 導入が簡単 ストーリー駆動開発できる デメリット: Webpackの機能で動いてる まとめ 前回のあらすじ developer.hatenastaff.com 前回の記事では、Reactコンポーネントをnpmパッケージとして開発する方法を紹介しました。 対象としたのはこちらの無限スクロール用のReactコンポーネント。 http://www.npmjs.org/package/@fand/react-infini
webpack で始めるイマドキのフロントエンド開発 - Qiita
webpack とは webpack は WebApp に必要なリソースの依存関係を解決し、アセット（配布物）を生成するビルドツール（要するにコンパイラ）です。JavaScript だけでなく、CoffeeScript や TypeScript、CSS 系、画像ファイルなどを扱うことができます。 WebApp のビルドツールは Grunt や Gulp が有名です。これらは基本的に、ビルド手順をタスクという形で自ら定義する必要があり、フロントエンド開発に馴染みのない開発者にとっては敷居が高いものでした（少なくとも、自分はそうでした）。 webpack を使えば、Grunt も Gulp も必要ありません！覚えるべきことはほとんどありません。（必要なら）簡単な設定ファイルを書いて webpack コマンドを実行するだけです。 以下では基本的な使い方を見ていきます。 ※もちろん Grunt/G
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tips on Setting up Karma Testing with Webpack