npm ciを使おう あるいはより速く - Qiita
人類はより高速にCIを回していくべきだと思っている りんご（@mstssk）です。 先日、 npm の v5.7がリリースされ npm ci というサブコマンドが新たに追加されました。 The npm Blog — Introducing npm ci for faster, more reliable... http://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable CI/CDを開発プロセスに組み込んでいる場合により整合性があり高速なエクスペリエンスを提供する、と公式ブログでは紹介しています。 npm ci は何をするのか npm ci を実行すると常に package-lock.json から依存関係をインストールします。 既に node_modules フォルダの中身があっても
lerna README.md 日本語訳 - Qiita
2017/1/17 v2.0.0-beta.31時点でのREADME.mdのほぼGoogle翻訳です。勝手にやったのでまずかったら消します！ A tool for managing JavaScript projects with multiple packages. About Splitting up large codebases into separate independently versioned packages is extremely useful for code sharing. However, making changes across many repositories is messy and difficult to track, and testing across repositories gets complicated really fast. 大
Goのパッケージ構成の失敗遍歴と現状確認
この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう
今となって後悔しているkamiのこと - Qiita
クリスマス期間になると喜ぶ人もいれば悲しむ人もいる。そんな極端な季節の中で、自分が作ったguregu/kamiというWAFについて真面目に考えた。contextの正しい使い方や、kamiのAPIで後悔していることを晒そう。 kamiを作ったきっかけ まずはkamiの歴史について簡単に説明する。GunosyでアプリのAPIサーバーをRailsからGoに少しずつ書き直していたが、モノリシックだったmodelsとhandlersパッケージが大きくなりすぎて分かりにくくなってしまった。大きいパッケージを複数の小さなパッケージに分けようと思った。しかしユーザーのセッション情報などは様々なパッケージにどう共有したらいいでしょう？ 当時使っていたGojiというWAFでは、リクエストごとにEnvというmap[string]interface{}が付いていた。 これを使えば、どんなパッケジーにHTTPハンド
CIでLerna publishするまで - Qiita
絶対に忘れる自信があるので今のうちにメモっておく。 Lerna is 何 Lerna はmonorepoを管理するためのツール Babelのように、単一レポジトリで複数のnpmパッケージを管理できる レポジトリ内パッケージ間の依存関係をsimlinkにより解決してくれる（勝手に npm link してくれるイメージ） やりたいこと 開発者がmasterへコード修正commit(PRのmergeなど) CIでテスト実行 開発者がリリース意思表示 CIでリリース実行 lerna publish が実行されて、npmへpublish完了! 今回はCIサービスにはCircleCI(2.x)を選択。 特にCircleCIにこだわっているわけでもなく、workflow的な仕組みが備わっているCI Serviceであれば問題ないはず。WerckerCIとか。 準備 lerna publish は下記を逐
npmからkikとその他諸々が消されたまとめ
npmとは、node.jsにおけるパッケージシステムのことだ。npmを使えば、他人の書いたnode.jsベースのプログラムとライブラリの入手と利用がとても簡単になる。 そのnpm界隈が混乱している。発端は以下のURLだ。 I’ve Just Liberated My Modules — Medium Azer Koçuluはkikという名前のnpmパッケージを公開していた。このkikというソフトウェアの中身についてはここでは関係がない。 さて、それとは別に、kik.comというスマフォ用のチャットアプリを出しているKik Interactive社がいて、kikという名前のパッケージをnpmで出したいので、名前を明け渡すように要求した。 Azerはこの要求を拒否した。すると、Kik Interactive社はnpmの管理者に片っ端からメールを投げまくり、そのうちの一人が反応して、Azerの意
npm パッケージの unpublish に関するゴタゴタの大まかなまとめ - ヤルキデナイズド
（最終更新：3月24日16:50ごろ） 事件の流れ kik の作者が同名の会社 KIK の弁護士特許出願代理人からパッケージ名を変更するよう要請される 作者が拒否したところ弁護士代理人は npm の運営にコンタクトする 運営が作者の許可なくパッケージを unpublish するパッケージの所有権を移し替える 作者がこれに反発し自身が所有する270あまりのパッケージをすべて unpublish する I’ve Just Liberated My Modules — Medium unpublish されたパッケージは npmjs.com からダウンロードできなくなる unpublish されたうちのひとつである left-pad に間接的に依存したパッケージが多数あったため世界中でビルドがぶっ壊れる npmjs.org tells me that left-pad is not availa
npm-shrinkwrap.jsonが壊れた時、対処にめっちゃ時間がかかる - マルシテイア
いつの間にかnpm-shrinkwrap.jsonが壊れてて、真っ更な状態から環境構築しようとするとエラーが出るようになった。 実際に出るエラーは npm ERR! install trying to install 0.9.11 to /Users/amagitakayosi/XXX/node_modules/babel-runtime/node_modules/core-js npm ERR! install but already installed versions [ '1.2.1' ] といった感じ。 このエラーは、複数のパッケージのpeerDependencyでcore-jsが指定されていて、かつバージョンがバラバラの時に起きる。 明示的に npm i -D core-js とすると直る。 あるいは、 npm i -g core-js としても直るらしい？ ただ、今回はこのエ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
babel6での変更点 Gulp・Webpackの設定 - Qiita