最近JSを利用するときは、依存モジュールはnpmを利用し、ES6やTypeScriptの仕様を開発には使った上で、ブラウザ用にコンパイルして配信するようになってきている。また同時にネットワークの負荷を下げるためにminifyを行う場合もある。 minifyはライセンスが絡むと少し難しい。例えばコメントを全て削除してしまうとライセンスコメントまで消えてしまう。この問題にはみんながそれぞれの手法で対処しているみたい。1年ほど前の記事でクライアントサイドJavaScriptのライセンス管理 | エンジニアブログ | GREE Engineering というものがあり、いろんなJSのコンパイルのためのライブラリが独自でライセンスの形式を決めていて、それにマッチしないものは消えてしまう、みたいな辛いことが起きてそうだった。 そこで今回は自分の勉強も兼ねて、npmのモジュールを含めてブラウザ用にコンパ
これまで NW.js を使ってきたが同じ Chromium + Node 系のフレームワークとして最近は Electron のほうが勢いあるようなので試したくなった。使用感を把握するため、まずは開発環境を構築してみる。 更新履歴 2015/11/5 npm-scripts を babelify 7.2 (Babel 6.x) を採用した内容へ更新。また最新 watchify の Windows 対応について追記した。これらの詳細については babelify v7.2 を試すを参照のこと。 2015/10/19 npm-scripts を最新へ更新、Main プロセスのビルド説明に Browserify の --node オプション解説を追加。 設計方針 package.json と npm だけを使用 AltCSS は Stylus を採用 ユニット テスト対応 コード ドキュメント対応
ReactとMaterial UIを組み合わせると、それだけでBrowserifyで結合したJavaScriptファイルが1MB超えてしまうので、やっぱり圧縮とかした方が良いのかな―と思い、やり方を調べてみました。 ※2015/08/03更新 Licensifyを開発された @t_wada さんから改良の連絡をいただいたので、Licensifyの最新版1.4.0をもとに内容を更新しました。 Licensify - Nodeモジュールのライセンスコメントを生成する JSファイルを圧縮すると、ライセンスが記載されているコメントが消えてしまうという問題があるということで、本題の前に、Browserifyと組み合わせて、読み込んだNodeモジュールのライセンスコメントを生成してくれる Licensify を試しておくことにしました。 インストールはnpmから。 $ npm install lice
皆さんこんにちは。adingoにてFluctという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。 今回は、表題の通り、実際にプロダクトとして動いている既存のコードベースを、ES5ベースからTypeScriptに段階的に移行させた話について書こうと思います。 移行前のコードベース及び直面した課題 今年の1月頃から、アプリケーションのクライアント側の一部を、以下の構成で実際に開発しています。 言語 ECMAScript 5 主要な依存ライブラリ UI開発にReactおよびFacebook JSX syntax 統合イベントシステムとしてのRxJS テストコードのアサーションにpower-assert ビルドチェーン モジュール連結にbrowserify 環境変数に基づくビルドフラグ用途でenvify コードの解析とLintにESLint 未使用変数や未定
Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address. browserify for webpack users There's been a strange explosion in misinformation about browserify recently, particularly in comparisons to webpack. Generally speaking, most of this confusion stems from how webpack is more willing to pull features into its core to ease discoverability while browserify is more lik
最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
かめ板 es6-Kameita ahomu/es6-Kameita es6-Kameita は ECMAScript 6 で JavaScript ライブラリを開発するためのプロジェクトスケルトン(テンプレート)です。初期設定はブラウザ向けですが、Nodeモジュールにも対応します。 6to5 でトランスパイルされたコードを Browserify でビルドし、mocha + power-assert でテストを実行します。Browserify を採用しているため、初期状態では bower に依存せず npm を活かしています。 経緯 6to5/6to5 がリリースされて以来、しばらく手元で ES6 を使い続けていたので、ぼちぼち開発の構成を固めてしまいたいなと思った次第。 最初は GianlucaGuarini/es6-project-starter-kit を fork して何とかしようと
前々から出すよ出すよ詐欺してたflowがやっと出た。大雑把にはfacebook製のTypeScriptだと思っていれば良いです。 まだnpmで提供されてなくて、 Flow | Getting started with Flow で実行バイナリが配られてる。 npmで提供されてない理由は、たぶんocamlで書かれてるから。Future Planにjs_of_ocamlでコンパイルされたものが提供されると書いてあった。 DLして適当なパス通った場所に置いてつかう。 TypeScriptとの比較 思想はTypeScriptと同じなので、大枠は一緒だといってよい。 ぱっと見気になったのは、Nullableの書式が違うのとかあるけど、もっと大きな違いもたくさんある。 FlowとTypeScriptにあるもの declareキーワードによるアノテーション ES6 classes Generics ここ
About My personal thinking on certain things regarding development and stuff... http://www.benoitvinay.com ben@benoitvinay.com I’ve been looking a bit at dependencies injection in JS. A co-worker talked to me about Browserify and I really like it. It is really simple to setup with Grunt using grunt-browserify and it works like a dream… Because it is part of my workflow now, I’ve decided to change
Browserify を触ってみたメモ。 Browserify とは CommonJS のモジュールの仕組み、つまり Node.js の require をブラウザ上でも使えるようにするもの、ということでいいみたい。Readme を読む限りは、npm にあるモジュールをブラウザ上にもっていくために作られ始めたような印象をうけるが、ちまたのエントリーをみていると AMD に代わりに CommonJS でフロントエンドの依存関係の管理をする (RequireJS ではなく、Node.js 感覚で require 関数をフロントエンドで使う) ためのツールとしても使っていいようだ。 やりたいこと 複数の js ファイルの依存関係を記述したい 最終的に、依存関係を考慮した順番で、ひとつの js ファイルに結合したい 作りたいのは第三者のサイトに埋め込んでもらうスクリプト (サードパーティスクリプト
Node.jsでフロントエンドもバックエンドもJSのプロジェクトをはじめる際に、 それぞれのパッケージ管理をどのようにするか悩んだ記録。 要件としては、 1.フロントエンドもrequireでmoduleの探索をしたい 2.フロントエンドとバックエンドでパッケージ管理を分けたい 1を満たすためにcomponent.jsかbrowserifyか悩んだ。 browserifyは作りが怖かったが、component.jsはもっと怖かった。 browserifyを単純に使うとnode_modulesを共有してしまうので、 2が満たせない。debowerifyというpluginがあるようなので、 フロントエンドはbower_components/にという方針でやってみた。 // バックエンドの依存管理 package.json // バックエンドのパッケージ置き場 node_module/* // バ
最近だとGrunt使ったりgulp使ったり、またはGoogleのWeb Starter Kit使ったりしてセットアップすることが多いと思います。 ただ、何かを新しいフレームワークを試したりしたいだけのときにこれらの設定ファイルとか無駄に増えるのもイヤだなと思ったりしていて、最近はbrowserifyとbeefy使ってやっています。 https://www.npmjs.org/package/browserify https://www.npmjs.org/package/beefy 各種変換とLiveReloadが出来れば十分なので。 例はこんな感じ。 https://github.com/koba04/react-boilerplate 設定ファイルがpackage.jsonだけになるのでシンプルです。 package.json 設定はこんな感じでしておくだけです。scriptの設定をし
browserify-as-a-service Places fork me on github browserify on the web browser-module-sandbox - helpful for using multi-bundles requirebin.com - powered by wzrd.in esnextb.in - also powered by wzrd.in Quick Start Try visiting this link: /standalone/concat-stream@latest Or choose a module here:Module:Version: What just happened? Well, in this case, since someone has visited this link before you, th
Rails-like JavaScript Using CoffeeScript, Backbone.js and JasmineRaimonds Simanovskis
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く