Yarn + CI + GitHub で挑む npm パッケージの定期更新Greenkeeper を使わない npm パッケージの更新戦略について提案です
npm | the state of javascript frameworks | part 3 | backend frameworks
The State of JavaScript Frameworks, 2017 Laurie Voss, co-founder and COO, npm, Inc. January 3rd, 2018 Part 3: Back-End Frameworks The story on the back end is simple: Express is the overwhelmingly dominant solution for back end services written in JavaScript. The next four biggest frameworks are so small relative to Express that it’s hard to even see them. The other clear pattern here is that Expr
thank-you-starsで利用しているnpmパッケージに気軽にスターを送る - teppeis blog
先週、こういうツイートを見て、 OSSを使っているなら、GitHubのリポジトリにそっとスターをつけると開発者のキャリアにわりと直接的に貢献できるのでお薦めです。少額の寄付より効果があるかも— Taro L. Saito (@taroleo) 2017年8月15日 共感したのでサクッと作った。 github.com package.jsonと同じディレクトリで実行するだけで、depsとdevDepsのパッケージのGitHubリポジトリにスターできる。 事前にパーソナルトークンをホームディレクトリに保存しておく必要があるけど、その辺はREADMEを読んでくれ。 依存に入れて使っているということは、それなりに恩恵を受けているということなので、問答無用でスターを送ってしまって良いと思う。 孫依存のパッケージにも送るか迷ったけど、npm的にそこ含めると一気に数が膨れてしまうのでやめた。 これでみん
更新が必要なnpmパッケージを可視化する - Hatena Developer Blog
こんにちは。ウェブアプリケーションエンジニアのid:masawadaです。普段は、はてなブログチームで開発を行なっています。 今回は、日々の開発で生まれた困りごとを解消するために作ったyarn-outdated-formatterというツールを紹介します。 経緯 以前id:amagitakayosiが「フロントエンドPodcastはじめました - Hatena Developer Blog」にて書いたとおり、はてなには現在「フロントエンドエンジニア」という肩書きのメンバーはいません。はてなブログチームでも全員がバックエンド(Perl)とフロントエンド(JavaScript)両方のコードを書いており、どちらかというとバックエンドがメインのためクライアントサイドは片手間になりがちという問題がありました。 そこで、チーム内でFWG(フロントエンド・ワーキング・グループ)という会を組織しました。F
npmjs.com で著名ソフトウェアによく似た名前のマルウェアが大量に発見された - Islands in the byte stream
Malicious packages in npm. Here’s what to do | Ivan Akulov’s blog People found malicious packages in npm that work like real ones, are named similarly real ones, but collect and send your process environment to a third-party server when you install them 訳: 悪意のあるパッケージがnpmで発見された。それらは、実際のパッケージによく似た名前で同じように動くが、パッケージのインストール時にプロセスの環境変数を外部のサーバに送信する。 発見されたパッケージの一覧は元エントリをどうぞ。このようなマルウェアである偽パッケージの一例をあげると、 ba
JavaScript モジュールの現状 | POSTD
(注：2017/07/19、いただいたフィードバックを元に翻訳を修正いたしました。) ESM、CJS、UMD、AMD — どれを使うべき？ 最近、 Twitter では、 ESモジュール の現状、特に、 *.mjs をファイル拡張子として導入すると決めた Node.js の現状について大騒ぎになっています。この話題は複雑で、かなりの労力を費やしてそれに専念しないと議論について行けないので、 皆が恐れと不安を抱く のも無理はありません。 古き恐れ フロントエンド開発者なら、 JavaScriptの依存関係の管理に悩まされた日々 を憶えている人も多いでしょう。あの頃は、ライブラリをベンダーフォルダにコピー&ペーストし、グローバル変数に依存し、あらゆる物を正しい順序でconcatしようとしてもネームスペースの問題に対処する必要がありました。 何年もかかって、私たちは共通モジュール形式と中央集権
MOPID | Accelerate Your Hiring Process - Hire the Best, 10x Faster
Hire the best. At 10x the speed.Hire the best. At 10x the speed.Screen and interview candidates 10x faster with MOPID AI Recruiter that saves upto 80% of your time and resources. Hiring 100+ positions? Try⚡Blitzhiring⚡for a change!Hiring 100+ positions?Try ⚡Blitzhiring⚡ for a changeWe get it. Large scale hiring costs a lot. What if you could hire the perfect talent AND save up to 80% resources? We
Svelte • The magical disappearing UI framework
Svelte is a UI framework that uses a compiler to let you write breathtakingly concise components that do minimal work in the browser, using languages you already know — HTML, CSS and JavaScript. It’s a love letter to web development. But don’t take our word for it. Developers consistently rank Svelte as the framework they’re most excited about using.
JavaScriptのトレンドを素振りして確認する方法 - Qiita
JavaScriptは流れが早いと言われますが、その流れをどう捉えるかの一つの要素として使える素振りの話です。 流行り廃れが早いのはちゃんと循環してるということなので問題ないですが、 トレンドと言われるものの半分ぐらいは誰かの主張にすぎない事があります。 そのため、主張だけを見て判断しないで中身を見て確認する必要があります。 自分はJSer.infoというJavaScriptの情報サイトを2^8週間ほど継続してやっています。(5周年記念イベントを1/16(土)にやります) JSer.infoで紹介するものは何かしらの方法でその主張がおかしくないかの確認をとります。 売り文句は素晴らしいが中身を見た時におかしな部分や問題がありそうなら、そこで引き返して追わないという判断もします。 仮にそこで引き返した事が間違えであっても、それが素晴らしいものなら別の誰かがそういう主張を書いてくれるはずなので
npm-scripts で使える便利モジュールたち - Qiita
npm はパッケージ依存管理ツールであると同時に、便利なタスク・ランナーです。 本体はごく基礎的な機能だけを持ち、npm が管理するパッケージと Shell の力を組み合わせてタスクを定義します。「npm-scripts で利用する CLI コマンドは npm で管理できる」という分かりやすさが気に入っています。 npm-scripts には以下の特徴があります。 多くのツールが CLI を持っているためにラッパープラグインが不要です。Gulp ラッパー プラグインは非公式であることも多く、メンテナンスが継続するか不安な場合があります。 簡潔です。Gulp で書くと数十行だった処理が数行になるなんてこともよくあります。 複雑なことをするには向いていないです。 環境変数の扱いに難があります。 この記事では、私が npm-scripts を書くときによく利用している便利ツールたちを紹介します。
Node学園 23時限目 アウトラインメモ
Node学園 23時限目 (今回はリクルート（東京駅）でやります！) - connpassに参加してきたのメモ npm@4、npm@5 node-gakuen-201610.md npmは後方互換性を重んじている Node.jsにbundleされているので npm@2のbreaking changeについて backwards-incompatible change to the way npm run-script handled its arguments npm@3 flat directory npm@2そのまま使い続ける人もいる 大きな変更は移行の壁になるという話 npm@4 Release v4.0.0 · npm/npm npm 4は小さな変更にした prepublish が npm install 時に実行されるのは Deprecated prepublishOnly と
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 コ
package.json の browser field 実践編 - Qiita
package.json の browser field 実践編 package.json の browser field 入門編 では、package.jsonのbrowser fieldの役割と機能について紹介しました。 本編では、この機能のbundlerごとの実装の違いと、それを回避する方法を説明します。 ここで取り上げる実装の違いとはずばりpathの解決方法です。 ./から記述するかどうか .jsを記述するかどうか mainとの対応関係 この3つの要素が絡んできます。 なお、パス解決のresolverを指定できる系もあるようですが、ここでは各々のbundlerがデフォルトで用意しているresolverについて論じています。 (なぜなら、resolverを外部が指定しなければ意図通りbundleされないというのは、利用者にとってはbundleされないのとほぼ同義です) 調査したbun
project毎のnpmコマンドをいい感じにするnpmrc & config達 - Qiita
npmrcのドキュメントを読みなおしていたら、.npmrcは/path/to/my/project/.npmrcのようにプロジェクト毎に配置することが出来る事に気づいて、ちょっと使ってみたら便利だった。 globalやhomeディレクトリへの設定を前提としたnpm configの記事は結構あるが、プロジェクト毎でnpm-configについて書かれている記事があんまり無かったのでまとめてみる。 npm-configの何が良いのか？ project毎に出来ると何が良いのか？ npm-configの設定をすると、色々コマンドを省略出来たりして良い事がある。 (参考:2016年版 Node.jsで幸せになれる10の習慣) npmrcやnpm-configは、個人開発用であれば、$HOME/.npmrcへの設定だったりnpm config setでの設定で十分。 また、npm registryに登録
npm dependenciesを更新してGitHub Compare Viewのリンク付きでPRするツールを定期実行する - Islands in the byte stream
タイトルに要素を詰め込みすぎましたが、要は CircleCIを使ってbundle updateを定期実行する - Qiita の npm update 版です。web appのJavaScriptライブラリ管理にnpmを使うとき、依存関係のアップデートを継続的に行うためのツールです。 https://github.com/bitjourney/ci-npm-update これはいまのところGitHub専用です*1。CIサービスはドッグフーディングも兼ねてCircle CI用の起動スクリプトを同梱してますが、実際には ci-npm-update を定期実行するだけなので簡単に代替可能です。 これはCircle CI + Heroku Schedulerで動かしていて、以下のようなフローです。Circle CIはJenkins含め他のCIでも動かせますし、Heroku Schedulerはcr
毎週のように依存パッケージを上げ続ける努力 - CARTA TECH BLOG
皆さんこんにちは。fluctにてfluct SSPという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。 依存パッケージの更新、どうしてますか？ 今や数多くの言語でパッケージマネージャが提供されており、みなさんも日常的にコミュニティによるパッケージエコシステムを活用していることと思います。 ですが、この依存パッケージの更新については、どのようにしていますか？ セキュリティfixなどを除き、以下のようなことになっていることが多いのではないでしょうか？ チームの「いい人」が頑張って更新し続ける その人の謎の情熱が消えると更新されなくなってしまう たまに気がついたら頑張る 「いい人」が頑張るタイプの亜種 気が付かなかったら更新されない 更新はリスクなので塩漬けにする プロダクトは定期的に作り直す前提 CIでテストを回し続けているのに更新しないなんて……とモヤ
自分が依存しまくってる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
ESLintの設定をscoped packageでnpmにあげて使い回す - Qiita
ESLintがv2にアップデートしてからけっこう変わって、だましだましv1系の設定をいじりながら使い続きてたけどだいぶカオスになってきたので気合入れて書き直した。 せっかく気合入れて書いたのでプロジェクトを横断して設定を共有できるようにしたい。 ESLintの設定を使い回すのはいくつか方法が考えられる。 プロジェクトごとにコピペする npmモジュールにしてextendする さらにnpmモジュールとして利用するのはいくつか方法があって、 eslint-config-hokacchaみたいにグローバルな名前でnpmにpublishして使う scoped packageとして@hokaccha/eslint-configみたいな名前でnpmにpublishして使う githubに置いといてnpm install hokaccha/eslint-configみたいにして使う たぶん1が一番メジャー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Workbox Broadcast Cache Update | Workbox | Google Developers
Search javascript libraries