pnpm の特徴
$ pnpm install express Packages: +57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Packages are hard linked from the content-addressable store to the virtual store. Content-addressable store is at: ~/Library/pnpm/store/v3 Virtual store is at: node_modules/.pnpm Progress: resolved 61, reused 0, downloaded 57, added 57, done dependencies: + express 4.18.1 ディスク容量が節約された node_modules 「Packa
[TypeScript]モノレポ管理ツール比較検討
モノレポ管理のツールを検討したときのメモ Background 自分が所属するチームで開発する JavaScript/TypeScript のプロダクトが増えてきて、同じような内容のリポジトリがいくつも存在している（n個とする）。 変更を加えていくにつれて、それぞれの差分が大きくなり、以下のような問題が発生する。 開発が止まっているプロジェクトの構成が古くなり、修正コストが発生する 開発が複数同時進行している場合、同じような実装を手動で同期する必要がある これらは共通の基盤等があれば効率的に（理想的にはn分の1の労力で）開発が可能であり、将来的なコストを考えると、いまのうちにその仕組みを考えておきたい。 Proposed Solutions 要件は以下 複数のパッケージをnpmとしてpublishできる アプリケーションも管理できる Nx, Rush, Lerna を主要な選択肢としている
![[TypeScript]モノレポ管理ツール比較検討](https://cdn-ak-scissors.b.st-hatena.com/image/square/e204665caf2bdc344987086461dd0424f7c8112d/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--mp4vbqB0--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BTypeScript%25255D%2525E3%252583%2525A2%2525E3%252583%25258E%2525E3%252583%2525AC%2525E3%252583%25259D%2525E7%2525AE%2525A1%2525E7%252590%252586%2525E3%252583%252584%2525E3%252583%2525BC%2525E3%252583%2525AB%2525E6%2525AF%252594%2525E8%2525BC%252583%2525E6%2525A4%25259C%2525E8%2525A8%25258E%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Aokmttdhr%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2I5NmZlMjc4YTYuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
フロントエンド開発でパッケージのアップデートを継続的におこなう - Qiita
フロントエンド開発でパッケージのアップデートを継続的におこなう これは Classi Advent Calendar 2018 1 日目の記事です。 フロントエンドエンジニアの @kasaharu です。 はじめに 昨今のフロントエンド開発はフレームワークと呼ばれるものから便利なライブラリまで幅広いパッケージを使って行われている しかし、これらは導入したときのままであることが多く、バージョンアップすることを怠ると後々問題の原因になったりする バージョンを上げないとセキュリティ問題に対応できなくなったり、パッケージそのものがサポートされなくなったりする また、逆にバージョンを上げることでパフォーマンス改善などの恩恵を受けられる場合もあるが、その機会を損失していたりする 今回は、できるだけ負荷にならずに継続的なパッケージアップデートを習慣化するために Renovate というサービスを使用して
Introducing npx: an npm package runner
[You can also read this post in Russian.] Those of you upgrading npm to its latest version, npm@5.2.0, might notice that it installs a new binary alongside the usual npm: npx. npx is a tool intended to help round out the experience of using packages from the npm registry — the same way npm makes it super easy to install and manage dependencies hosted on the registry, npx makes it easy to use CLI t
package.json のチルダ(~) とキャレット(^) - Qiita
バージョン指定でいっつもこいつの違いを忘れてしまって、npm とか semver のドキュメントを探すところから始まるから自分用のメモ。 ^1.1.2 = 1.x ~1.1.2 = 1.1.x (追記 一応↑は間違っていないのだけど、厳密にいうとちょっと間違っていた) チルダ表記 ~ "明記したところ以下のバージョンがあがることのみ許容" ~1.1.2 = 1.1.2 <= version < 1.2.0 ~1.1 = 1.1.x ~1 = 1.x オリジナルの定義は、 Allows patch-level changes if a minor version is specified on the comparator. Allows minor-level changes if not. キャレット表記 ^ "一番左側にある、ゼロでないバージョニングは変えない (それ以下があがることは
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
Brunch | ultra-fast HTML5 build tool
var app, base, concat, directory, gulp, gutil, hostname, path, refresh, sass, uglify, del, connect, autoprefixer, babel; var autoPrefixBrowserList = ['last 2 version', 'safari 5', 'ie 8', 'ie 9', 'opera 12.1', 'ios 6', 'android 4']; gulp = require('gulp'); gutil = require('gulp-util'); concat = require('gulp-concat'); uglify = require('gulp-uglify'); sass = require('gulp-sass'); connect = require(
npm_lazy - A lazy local cache for npm
npm_lazy A lazy local cache for npm Why? npm can be slow, down or return random errors if you have large deploys npm_lazy caches packages on your local network, making things faster and more predictable If 100 servers request the same package metadata at the same time, npm_lazy makes sure that (at most) only one request goes out to the npm registry. No database to install, replicate or manage. Dat
Vercel: Build and deploy the best web experiences with the Frontend Cloud – Vercel
Your complete platform for the web.Vercel provides the developer tools and cloud infrastructure to build, scale, and secure a faster, more personalized web. Your complete platform for the web.Vercel provides the developer tools and cloud infrastructure to build, scale, and secure a faster, more personalized web.
Why Npm Scripts? | CSS-Tricks
DigitalOcean provides cloud products for every stage of your journey. Get started with $200 in free credit! There has been a growing sentiment (for instance) that using node packages directly, with the command line interfaces they provide, is a good route to take. As opposed to abstracting the functionality away behind a task runner. Partly: you use npm anyway, npm provides scripting functionality
[意訳]私がGulpとGruntを手放した理由 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? このポストは、Why I Left Gulp and Grunt for npm Scriptsを筆者の許諾を得て意訳したものです。間違いがありましたら、ご指摘いただけると幸いです。 （以下、訳） 私はGulpとGruntが不要な抽象化レイヤーだと気づきました。npmのscriptsはとても強力で、そっちの方が便利だったりします。 例を挙げましょう 私はかつてはGulpが大好きでした。しかし結局のところ、100行ものgulpfileと大量のgulpプラグインを扱うハメになりました。Gulp上でWebpackやBrowsersync、Mo
![[意訳]私がGulpとGruntを手放した理由 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/0621c3c9d0b907a9995f242e813815fc82f9b5f2/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU2JTg0JThGJUU4JUE4JUIzJTVEJUU3JUE3JTgxJUUzJTgxJThDR3VscCVFMyU4MSVBOEdydW50JUUzJTgyJTkyJUU2JTg5JThCJUU2JTk0JUJFJUUzJTgxJTk3JUUzJTgxJTlGJUU3JTkwJTg2JUU3JTk0JUIxJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0wOWExMDJhNzUzNjYwYTQ1ZGRkN2MwYTBlMDAzNzBlZg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB0ZW5rZWkmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWU0ZDBkYTlmMDFjMGU5NTYwNGZlNTcxYTVjMDEyOWI3%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dc16c188bed223bc3c3cb38615a4aa3c0)
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
Grunt/Gulpで憔悴したおっさんの話 | MOL
先人たちが1年前に通った道で、いろいろいまさらかよって話なんですが。基本的に以下の記事読んだら分かります。要はGulpとかGruntといったモノ使わずにnpm run hogehogeでビルドしよーぜって話です。 task automation with npm run オレ的Gruntに対する最新の気持ち - from scratch Node - npm で依存もタスクも一元化する How to Use npm as a Build Tool // package.json "scripts": { "start": "npm run start-serve & npm run watch", "test": "stylestats public/files/css/maple.css", "start-serve": "browser-sync start --server publ
最近あまり使ってない、流行っていた時期もあるフロントエンドもの
最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
npm で依存もタスクも一元化する - Qiita
タスク管理 package.json にはパッケージの依存を書いて npm install するのが基本だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、
コマンドパスを自動で通し npm install -g しない - Qiita
追記 @hokaccha さんの指摘反映 npm install -g cosidered harmful 何かコマンドラインツールなどが必要なために npm install -g を強要するリポジトリがたまにある。 もっと面倒なのは、依存するツールがあるくせに README とかに書いてない場合だ。リポジトリにある設定ファイルからこちらが察して入れてやらないといけない。 グローバルに入れるツールは package.json の管理外なので、そこのバージョンは指定できない。 入れれば済むなら良いけれど、同じコマンドを他のリポジトリでも使っているような場合、求められるバージョンが違ったりすると面倒だ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fast, disk space efficient package manager | pnpm
まだ node.js の依存性解決で消耗してるの？ | PLAID engineer blog
I’ve Just Liberated My Modules
For mission-critical Node.js applications - NodeSource
