色々あってシンプルなtypescriptの開発環境をつくろうとして消耗した話です 小規模なプロジェクトをシュって書けるシンプルな環境がほしい でもナウくなっててほしい そもそもナウいとは... 最近のフロントエンドの人は何を言ってるのか全然わからないし依存パッケージが多すぎて混乱する でもちょっとはナウくなっててほしい 試行錯誤した結果 npm scripts + browserify + tsify + watchify で構成することにきめた. 本体を1行も書かないまま日付が変わっていた. もうナウくなくていいから本体が書きたい 構成 とりあえずbuildすると色々なものがdistに送られる構成にした ├── dist (static-assets) │ ├── bundle.js │ ├── bundle.css │ └── index.html ├── src │ ├── ts │
制作部の金森です。 フロントエンドエンジニアとして働き初めて丸7ヶ月が経過しました。 この記事は mediba Advent Calendar 2016 の 16日目です。 フロントエンド開発の現場においてタスクランナーを使わない日はないほど重要なツールになっています。 みなさんはタスクランナーに何を使っていますか? 最新のフロントエンドツール使用調査結果からThe State of Front-End Tooling 2016 - Results に拠ると、 タスクランナーを使用しない人は 19.5% から 10.97% に減っているGrunt を好む人は 27.5% から 11.75% に減っているgulp を好む人が 43.69% と一番多いnpm-scripts を好む人は 22.8% 増え 25.95% にという結果が出ており、gulp が一番支持されているものの npm-scr
npm-run-all を使う github.com 使い方 npm i --save-dev npm-run-all でinstallします。 直列・並列実行コマンドの run-s, run-p が使えるようになります。 package.jsonのscripts部を以下のように設定してみます。 "scripts": { "dev": "run-p stub watch", "stub": "stubcell", "build": "webpack", "watch": "run-p watch:*", "watch:js": "watch 'npm run build' ./src/scripts" }, この状態で npm run dev とすると、stubサーバとjavascriptのwatch & buildが同時に走るようになります。 楽ちんですね。
gulp なしの Web フロントエンド開発から 1 年あまり。その間、特に問題もなく npm-scripts で Web フロントエンド開発を管理できているので、この間に得られた運用知見や所感などをまとめてみる。 npm-scrips とは? 最近の Web フロントエンド開発では AltJS/AltCSSのビルドやリリース用イメージ作成などに Node.js + npm を利用することが一般化してきた。そのためプロジェクトは package.json で管理することになる。package.json の提供する代表的な機能として プロジェクト情報の定義 プロジェクトの成果物を npm として配布するための情報 プロジェクト名、バージョン、作者などのメタデータを定義する 依存モジュール管理 プロジェクトが依存する npm とバージョンを管理する この情報へ基づき npm install コ
npmのpackage.jsonに以下のように書いていたら、明らかに実行されるファイルが少なくてどうしたものかと思っていました。 "scripts": { "test": "mocha --opts spec/client/support/default.opts spec/client/**/*.spec.js" } 理由は詳細には調べてませんが、おそらくこのスクリプトがzshではなくbashで実行されるためでしょう。 npm/npm#10481 によると、mochaは "**" をzsh的な意味で展開するのでそのまま渡せばいいということでした。 はたして以下のように書き換えるとちゃんと動きました。 "scripts": { "test": "mocha --opts spec/client/support/default.opts 'spec/client/**/*.spec.js'"
Web フロントエンド開発で npm の世界に触れ、いつか自分も作成してみたいと考えてた。 そんな折 Electron アプリ用にプラットフォームごとにアイコンを用意するのが面倒に感じていた。SVG から PNG を生成してそれを個別のツールでアイコン化。それほど頻繁に発生する作業ではないが、ファイル形式さえ満たせればクロス プラットフォームにできそうな処理だ。これは npm の題材としてちょうどよいのでは?ということで、そういう npm を作成してみた。 akabekobeko/npm-icon-gen icon-gen せっかくなので開発の過程に得られた知見を記録しておく。今後、新たに npm 開発するとき役立つかもしれない。 機能と設計方針 はじめに npm が実現する機能と設計方針を明確にしておく。 対象とするアイコン種別は以下 ICO ICNS Favicon 単一の SVG フ
↓を見てこれはよさそう!!と思ってやってみました。 http://qiita.com/mysticatea/items/12bb6579b9155fd74586 このパッケージを使うと、npmスクリプトから指定したページをブラウザで開くことができます。 Win/Mac/Linuxどの環境でも、同じスクリプトでブラウザを開けるのがいい感じ。 これは便利!! ここ最近、VSCodeからブラウザ開くタスク作れないかなぁ、、なんて思って色々調べてましたが、npmのパッケージを使って簡単にクロスプラットフォームに実現する方法がありました♪ 以下のコマンドでdevDependenciesに入れておいて、npmスクリプトからブラウザ開くのに使えます。 npm install opener --save-dev で、こんなnpmスクリプトを書いておくと、ブラウザを開くことができます。 "scripts":
npm はパッケージ依存管理ツールであると同時に、便利なタスク・ランナーです。 本体はごく基礎的な機能だけを持ち、npm が管理するパッケージと Shell の力を組み合わせてタスクを定義します。「npm-scripts で利用する CLI コマンドは npm で管理できる」という分かりやすさが気に入っています。 npm-scripts には以下の特徴があります。 多くのツールが CLI を持っているためにラッパープラグインが不要です。Gulp ラッパー プラグインは非公式であることも多く、メンテナンスが継続するか不安な場合があります。 簡潔です。Gulp で書くと数十行だった処理が数行になるなんてこともよくあります。 複雑なことをするには向いていないです。 環境変数の扱いに難があります。 この記事では、私が npm-scripts を書くときによく利用している便利ツールたちを紹介します。
I know what you’re thinking. WAT?! Didn’t Gulp just kill Grunt? Why can’t we just be content for a few minutes here in JavaScript land? I hear ya, but… I’ve found Gulp and Grunt to be unnecessary abstractions. npm scripts are plenty powerful and often easier to live with. Let’s Begin With An Example…I was a big fan of Gulp. But on my last project, I ended up with 100’s of lines in my gulpfile and
wait-on - wait for files, ports, sockets, http(s) resources wait-on is a cross-platform command line utility which will wait for files, ports, sockets, and http(s) resources to become available (or not available using reverse mode). Functionality is also available via a Node.js API. Cross-platform - runs everywhere Node.js runs (linux, unix, mac OS X, windows) wait-on will wait for period of time
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 のどちらでもパッケージ化できた。 この状況から察するに、アイコンの埋め込み処理などでプラットフォーム
これまで 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 を採用 ユニット テスト対応 コード ドキュメント対応
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く