npm-scripts で Web フロントエンド開発を管理する
gulp なしの Web フロントエンド開発から 1 年あまり。その間、特に問題もなく npm-scripts で Web フロントエンド開発を管理できているので、この間に得られた運用知見や所感などをまとめてみる。 npm-scrips とは？ 最近の Web フロントエンド開発では AltJS/AltCSSのビルドやリリース用イメージ作成などに Node.js + npm を利用することが一般化してきた。そのためプロジェクトは package.json で管理することになる。package.json の提供する代表的な機能として プロジェクト情報の定義 プロジェクトの成果物を npm として配布するための情報 プロジェクト名、バージョン、作者などのメタデータを定義する 依存モジュール管理 プロジェクトが依存する npm とバージョンを管理する この情報へ基づき npm install コ
Facebookが公開した新しいJavaScriptパッケージマネージャ: Yarn - オフトゥン大好き。
元記事： 素敵やーん。 日本時間で12日、ちょうど日付が変わったくらいにFacebookが前述の記事を公開した。内容は「JavaScriptコミュニティで圧倒的に力を持っているnpmの代替となる新しいパッケージマネージャ、Yarnを作ったぜ！」というもの。代替といってもYarnはnpmクライアントを完全に置き換えるものではなくて、上位互換を持ったものらしい。 npmに対して、Facebookはかなり前から依存パッケージのインストールにかかる時間を問題視していたみたいだ。これは僕や周囲のエンジニアの反応とも一致するし極めて妥当な感じがする。今回のYarn開発に関するモチベーションはそれだけではなく、同社のJavaScriptコードベースがエンジニアの数と共に肥大化していったことも述べていて、開発にグーグルが協力していることからも大規模サービスにおいてコード管理がいかに負担になっているかを物語
自分が依存しまくってるnpmパッケージを表示するツールつくった - マルシテイア
https://www.npmjs.com/package/what-do-i-depend-on github.com 先日のleft-pad騒動で、自分のプロジェクトのnode_modulesを慌ててチェックした。 普段依存の依存とかまったく意識してないけど、いざ見なおしてみるとその数の多さにビックリする。 全ての依存を把握するのは正直無理だけど、ざっと見てみるだけでも発見がある。 意外とscoped packageが使われてたり。めちゃくちゃミニマルなパッケージが人気だったり。 babel関係のパッケージが多すぎて目眩がしたり。 というわけで、自分のプロジェクトの依存パッケージを再帰的に調べて、依存度合いをチェックするツールを作った。 node_modules/ 内の package.json を再帰的に調べて、パッケージが登場した回数を表示する。 使い方 インストール npm i
フロントエンドで使ってるものがあまり変わってない - No Regrets in Bathing
自分のスタックはあまり変わっていない。ほとんど10年のツケを払っていない。学習能力が低いせいでもあり、選んだスタックがバージョンを重ねている成果でもある。 毎回使う フレームワーク：Vue.js 消耗、などの意見が散見されたが、べつに今でも便利に使えている。 browserifyやwebpackがあれば便利だけど、なくてもいい、ってバランスが好き データフローは特に考えない。状態がそこにあるので書き換えれば良い。 あまり頭を使わなくていいのが助かる Reactの考え方は好きなのだけど、よっしゃFluxやるぞって気持ちにはならず、Reactのみでよしなにやるソリューションが広まったらいいなと思う。 ビルドシステム： browserify / watchify substackの作るものはどれも品質が高いので、もうsubstack製品だけ使っていればいいやという気持ちになりがち。余計な処理が全
npm-scripts で使える便利モジュールたち - Qiita
npm はパッケージ依存管理ツールであると同時に、便利なタスク・ランナーです。 本体はごく基礎的な機能だけを持ち、npm が管理するパッケージと Shell の力を組み合わせてタスクを定義します。「npm-scripts で利用する CLI コマンドは npm で管理できる」という分かりやすさが気に入っています。 npm-scripts には以下の特徴があります。 多くのツールが CLI を持っているためにラッパープラグインが不要です。Gulp ラッパー プラグインは非公式であることも多く、メンテナンスが継続するか不安な場合があります。 簡潔です。Gulp で書くと数十行だった処理が数行になるなんてこともよくあります。 複雑なことをするには向いていないです。 環境変数の扱いに難があります。 この記事では、私が npm-scripts を書くときによく利用している便利ツールたちを紹介します。
JavaScriptのトレンドを素振りして確認する方法 - Qiita
JavaScriptは流れが早いと言われますが、その流れをどう捉えるかの一つの要素として使える素振りの話です。 流行り廃れが早いのはちゃんと循環してるということなので問題ないですが、 トレンドと言われるものの半分ぐらいは誰かの主張にすぎない事があります。 そのため、主張だけを見て判断しないで中身を見て確認する必要があります。 自分はJSer.infoというJavaScriptの情報サイトを2^8週間ほど継続してやっています。(5周年記念イベントを1/16(土)にやります) JSer.infoで紹介するものは何かしらの方法でその主張がおかしくないかの確認をとります。 売り文句は素晴らしいが中身を見た時におかしな部分や問題がありそうなら、そこで引き返して追わないという判断もします。 仮にそこで引き返した事が間違えであっても、それが素晴らしいものなら別の誰かがそういう主張を書いてくれるはずなので
npm i angular2してHello World!するところまで - Qiita
【160325追記】この記事はAngular 2 alpha時代に初稿を仕上げ、それ以降は変更にあわせて保守を続けていましたが、そろそろ差が大きくなってきたため改稿版として別の記事を用意しました。今後はそちらをご覧ください。 @armorik83です。初日である昨日は、このアドベントカレンダー最大のサプライズとして@btford氏に寄稿していただきました。アドベントカレンダーの立ち上げ直後からオファーし、日本の「アドベントカレンダー」という特殊なTech系の事情を説明し、Angular 2のカレンダーをぜひ飾ってほしいという旨で依頼したことを覚えています。直前になって、時差で向こうはまだ11月なため日本のカレンダー開始に気付いていなかった、という笑い話も乗り越え、公開にこぎ着けたことを喜ばしく思います。 Thank you so much for contributing! Angular
npm initでauthorやlicenseなどの初期値を指定する - teppeis blog
JavaScript Advent Calendar 2015の2日目。小ネタです。 npm initするときにauthorとかlicenseとか毎回同じこと入力するの面倒だったりしません？実はいくつかの項目は初期値を設定できるのだけど、ググってもあまり日本語情報が無いようなので共有。 設定方法は.npmrcで以下のように指定すればOK。 init-author-name=Teppei Sato init-author-email=teppeis@gmail.com .npmrcの場所は以下の順で優先される。（詳細は公式を参照） per-project config file (/path/to/my/project/.npmrc) per-user config file (~/.npmrc) global config file ($PREFIX/etc/npmrc) npm buil
ESLint をグローバルにインストールせずに使う - Qiita
はじめに ESLint 最初の一歩では、ESLint をグローバル インストールしていました。 グローバル インストールすると eslint コマンドにパスが通って便利ですが、欠点もあります。 プロジェクト毎に異なるバージョンの ESLint を使えない。 ESLint が互換性のないバージョンアップをした時に困る (1.0.0, 2.0.0 のようなメジャーバージョンアップは互換性がありません) 利用するプラグイン・共有設定もグローバル インストールしなければならない チームで同じバージョンに揃えるのが手間である npm のエコシステムでは、コマンドもプロジェクト ローカルにインストールして使うのが主流です。 そうすることで、package.jsonに依存バージョンとともに記述して共有することができます。 npm install 一発で、チームが同じ環境を揃えられるわけですね。 この記事
gulp なしの Web フロントエンド開発
JavaScript コンパイルとファイル監視 JavaScript ビルドは Browserify、ES6 から ES5 へのコンパイルは babelify を利用する。Source Maps ファイルは exorcist が生成。ファイル監視は watchify が担当。コマンド定義は以下。 { "scripts": { "build:js": "browserify -t babelify ./src/js/App.js -d | exorcist ./src/bundle.js.map > ./src/bundle.js", "watch:js": "watchify -v -t babelify ./src/js/App.js -o \"exorcist ./src/bundle.js.map > ./src/bundle.js\" -d", "release:js": "bro
npm で依存もタスクも一元化する - Qiita
タスク管理 package.json にはパッケージの依存を書いて npm install するのが基本だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、
気楽にECMAScript 2015したい
最近はOculus Riftとかを主にいじってるわけですけど、いわゆるHTML5も横目でウォッチしていて、たまにJavaScriptを書いたりもします。 で、今風にBabelを使って、かつわりと楽にゆるい感じでECMAScript 2015できるようにしておこうと思って、自分用のテンプレプロジェクトを作りました。Watchify＋Babelify＋BrowserSyncです。 KatsuomiK/ECMAScriptTemplate GitHubからcloneしてnpm installしてnpm run watchすればブラウザが起動して、.jsを書き換えればライブリロードがかかります。MacでもWindowsでも大丈夫のはずです。 package.jsonがこんな感じです。 { "name": "ECMAScriptTemplate", "version": "0.0.0", "desc
jspm で快適 javascript 生活（クライアントサイド JS の依存管理決定版） - Qiita
追記 config.js は常に自動生成されるものだと思っていましたが、その認識は誤りだったようです。 そのため、jspm_packages 下ではなく、public ディレクトリに設置するようにしました。 はじめに ぼくは Web の技術が大好き。 はじめに HTML 書いてブラウザで見たら表示されて感動したのを今でも覚えてる。 そんな調子でプログラミングの仕事について、ずっとそこらへんを書いてるけど、 最近の開発、めんどくせーこと多くないですか。 AltJS だー、React + JSX だー。ミニファイだー。依存の解決だー！ もちろん、必要なことだし、イケてるのもわかるけど、開発中に毎回 watch すんのもめんどいし...。と思っていた。 救世主 jspm 会社の人がなにげなく紹介していた jspm。 ビルドツールとかの「開発全体がキレイで楽になります！」っていうのが好きなので、試
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://duojs.org/