npm 開発で脱 Babel してみる - アカベコマイリ
自作 npm の開発で脱 Babel したときの対応と問題点まとめ。 2017/1/31 訂正 power-assert の作者、t_wada さんより power-assert は babel-register を通すなどしないと assert 置換が働かず素の assert になってしまうという指摘があったのでユニットテスト関連の記述を訂正 https://twitter.com/t_wada/status/826435235839504385 脱 Babel を決めた背景 私はいくつか自作 npm を公開している。これらは ES2015 以降の機能と構文を利用して npm publish の際に Babel で ES5 相当へ transpile している。この運用で特に問題も起きていない。またプリセットに babel-preset-latest を採用することで ES 関係の規格追
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 コ
npm-scripts でクロスプラットフォームに環境変数を参照するための npm を作成してみた - アカベコマイリ
以下の記事で npm-scripts から環境変数を参照する方法と問題点について書いた。 Electron を試す 7 – Electron v1.0 対応 npm-scripts で自前の環境変数を利用する方法と問題 課題として npm run するプラットフォームによって変数の参照記法が異なるため、それらを統一できない問題がある。npm-scripts でタスク管理したい派としては、どうしても解決したい。そこで対策用 npm を作成してみた。 cross-conf-env akabekobeko/npm-cross-conf-env 以下に npm の設計などをまとめる。 npm-scripts における環境変数の参照記法 冒頭のリンク先でも解説してあるが、改めて。package.json に定義された値を npm-scripts から環境変数として参照する場合の記法は以下となる。 P
Normalize.css を npm で管理して Stylus に組み込む - アカベコマイリ
これまで Stylus から Normalize.css を利用する場合、以下のように管理していた。 bymathias/normalize.styl から normalize.styl をダウンロード プロジェクトの src/stylus/lib フォルダ内に normalize.styl を配置 Stylus のエントリー ポイントで @import "lib/normalize.styl" つまり静的リソースとして扱い、バージョン更新があれば手動で置き換えていた。面倒な作業だが、CSS では JavaScript における npm と Browserify/webpack のようなリンカー的な仕組みが確立していないと考えており、また、更新も滅多にないことから放置していた。 しかしふと、Normalize.css のサイトをチェックしたら 公式 npm が用意されていた。また Styl
espower-babel から babel-preset-power-assert への移行 - アカベコマイリ
私は Web フロントエンドのテストで mocha + power-assert + espower-babel を組み合わせて利用しているのだが、これらのうち espower-babel が Deprecated になった。経緯と代替については以下の記事にまとまっている。 power-assert + babel as a development tool これからは espower-babel 代わりに babel-register と babel-preset-power-assert を利用。babel-register で require をフックして assert を power-assert へ置き換える。この処理が Babel ビルドの一環として実行されるようになった、という理解でよいのだろうか。 移行には npm 更新、.babelrc と mocha.opt 修正が必要
Atom を試す - アカベコマイリ
Sublime Text の利用パッケージと設定 2015で予告したとおり Sublime Text に近い環境を Atom で構築してみる。対象は現時点の最新 Atom v1.2.4 とする。 パッケージ管理 Atom は標準でパッケージ管理機能が組み込まれている。追加と削除、検索、設定も GUI ベースなのでわかりやすい。 紹介しているパッケージを検索する場合はメニューから Atom > Preferences を選ぶと Settings タブが表示される。その左メニューから Install を選択して検索窓にパッケージをコピペした後 Enter キーを押す。 検索結果にはパッケージ情報と共にダウンロード数も表示されるため、評価の目安になる。パッケージ情報の Install ボタンを押すことでインストールできる。 検索結果として既にインストールしたパッケージも混在して表示される。ここか
ESLint を試す - アカベコマイリ
これまで JavaScript の構文チェックに JSHint を利用していたが ES6 と React JSX に対応していること、より細かく柔軟なルール設定が可能なことから ESLint へ移行してみる。 ESLint - Pluggable JavaScript linter インストール ESLint は npm で配布されている。Sublime Text など様々なアプリから参照することになるだろうからグローバルにインストールしておく。 $ eslint -v v0.20.0 $ eslint -h eslint [options] file.js [file.js] [dir] Options: -h, --help Show help -c, --config path::String Use configuration from this file --rulesdir [
Windows で node-gyp を使った npm を動かすための環境構築 - アカベコマイリ
Electron の Starter プロジェクトで #7 Windows 版パッケージにバージョン情報リソースを含める を動作させるのに Node 以外で必要なものがあるため、それらの環境構築についてまとめる。 npm のなかに node-gyp というプラットフォームのネイティブ機能を利用するための npm を利用しているものがある場合、Windows 環境で npm install すると Python や CL.exe が見つからないというエラーが起きる。 これらを防ぐためには Node の他に Python と Visual C++ をインストールする。 Python Python のインストーラーは Download ページから入手。バージョンは 2.x 系と 3.x 系に分かれているのだが node-gyp が 3.x 対応していなさそうなのと Ansible など他のツール
Electron を試す 2 - パッケージ化におけるプラットフォーム固有処理とコンパイル分岐 - アカベコマイリ
Electron を試すで残された課題を解決したので、その内容を記録しておく。 2015/10/5 追記 本記事のはてブにて id:Pasta-Kさんより .ico ファイルを反映させるために wine が必要との指摘があった。試してみたところ OS X 環境でもアイコンとバージョン情報変更を反映した Windows 向けパッケージを生成できたので追記した。 electron-packager の --icon オプションに .ico ファイルを指定すると OS X でエラーになる問題だが Windows 環境で実行したらパッケージ化に成功。一方、Windows 環境だと OS X 版のパッケージ化がスキップされる。Linux 版は特別なオプションがないためか OS X と Windows のどちらでもパッケージ化できた。 この状況から察するに、アイコンの埋め込み処理などでプラットフォーム
Electron を試す - 開発環境の構築 - アカベコマイリ
これまで 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 を採用 ユニット テスト対応 コード ドキュメント対応
ESDoc を試す - アカベコマイリ
すると esdoc ディレクトリ内に解析結果となる HTML ファイルなどが出力される。 ESDoc をプロジェクトのローカルで使用する 最近 npm はなるべくプロジェクトのローカルにインストールしている。グローバルだと npm が更新されたときに依存しているプロジェクトすべてが影響を受ける。互換性の問題が起きたりしたら一大事だ。プロジェクトのローカルならそのような心配は無用である。 package.json で npm バージョンを管理することで、プロジェクトが必要とする依存も明示できる。ファイルを Git リポジトリなどで管理していれば環境の共有や復元も容易だ。 というわけで ESDoc もローカルへインストール。package.json の置かれたディレクトリで以下のコマンドを実行。ESDoc は開発用なので -D オプションをつけて package.json の devDepen
ES6 コードをテストする - アカベコマイリ
ES6 で書かれたコードをユニット テストしたい。できればテスト自体も ES6 で。という希望を実現してくれそうなツールがあったので試してみる。 mocha ユニット テストには mocha を利用する。業務で Node モジュールのテストに利用していて馴染みがあるのと後述する espower-babel が mocha を想定しているのがその理由。 mocha を npm test や npm run から利用するならインストールはローカルだけでよい。package.json 管理下にある npm にはパスが通った状態になる。 余談だが以下の記事を読んで gulp などもローカルにインストールして実行を npm で抽象化するほうがよいのでは？と考えるようになった。 npm で依存もタスクも一元化する 記事中にもメリットとして説明されているとおり利用者は npm だけ覚えればよい。グローバ
gulp なしの Web フロントエンド開発 - アカベコマイリ
Web フロントエンド開発において gulp は非常に便利だ。しかしあまりにも gulp に依存しすぎており、これなしで開発できるだろうか？という不安もある。というわけで gulp を利用せず package.json と npm だけで同等の機能を実現する方法を検討してみた。 2015/11/4 追記 babelify v7.2 を試すで babelyfy 7.2 ( とその中の Babel 6.x ) について調べ、npm-scripts の変更が必要なことを確認したので追記。また Windows 環境の動作検証をおこなったところ、最新の watchify なら -o オプションが通ることを確認できた。よって本記事の最後の課題が解決したことになる。 2015/9/23 追記 cpx と rimraf を試すの内容をファイル処理に反映して簡略化。 2015/9/15 修正 Stylus
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アカベコマイリ