Corepackを使ってNode.jsをアップデートする ⬆️⬆️
Corepackを使ってNode.jsをアップデートする ⬆️⬆️ 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info [.background-color: #FFFFFFF] Node.js 14は2023年4月でEOL Node.js 14.xは2023-04-30、Node.js 16.xは2023-09-11でEOL(End Of Life) 2023年10月からはNode.js 18と20のみがLTSとしてサポートされるバージョンとなる https://github.com/nodejs/release#release-schedule サマリ Node.jsのバージョンアップは面倒だけど ほとんどのBREAKING CHANGEはライブラリにある npmのバージョンアップは面倒 npm 6とnpm
まだyarnやnpmやpnpmの打ち間違いで消耗してるの？
まだパッケージマネージャーの打ち間違いで消耗してるの？ 初手煽りタイトル失礼します。よだかと申します。 僕はフリーランスでいくつかプロジェクトをやらせてもらっているのですが、プロジェクトごとにパッケージマネージャーが違ったりします。 これがかなり辛く、yarnのプロジェクトでnpm installしてpackage-lock.jsonを生成してしまったり、npmのプロジェクトでyarn installしてyarn.lockを生成してしまったり。。 果ては、yarn devなのか、npm run devなのか、など気をつけないいけないことがかなり多いです。 そこで今回ご紹介したいのがniというツールです。 niについて niについて説明するために、READMEを見てみましょう。 まずは一行目です。 npm i in a yarn project, again? F**k! とても強い思いから
corepack を使って npm/Yarn をお仕事的に安心して使う方法を考える | t28.dev
npm/Yarn どっちでも良いけれど、ちゃんと管理されていて欲しい プライベートでは npm 一択ですが、お仕事環境では「〇〇プロジェクトでは npm、△△ プロジェクトでは Yarn を使ってる。バージョン？分からん。」となることは、まぁあると思います。 パッケージマネージャーのバージョン違いによってどれほどの差分が発生するかは正直分からないのですが(lockfile のバージョン違いは除く)、 バージョンを揃えて再現性を持たせるのは基本ですよね！ でも「バージョンを patch まで指定してるから気をつけてね！」とお願いするだけだと お仕事的には意味がない し、辛みが深い。 作業するプロジェクトごとに npm/Yarn とそのバージョンのスムーズに切り替えたいし、間違えていたらエラーにもなって欲しい。 つまり「〇〇プロジェクトでは npm vx.y.x、△△ プロジェクトでは yar
GitHub - googleapis/gaxios: An HTTP request client that provides an axios like interface over top of node-fetch. Super lightweight. Supports proxies and all sorts of other stuff.
interface GaxiosOptions = { // The url to which the request should be sent. Required. url: string, // The HTTP method to use for the request. Defaults to `GET`. method: 'GET', // The base Url to use for the request. Prepended to the `url` property above. baseURL: 'https://example.com'; // The HTTP methods to be sent with the request. headers: { 'some': 'header' }, // The data to send in the body o
GitHub - pemistahl/grex-js: A JavaScript / WebAssembly library for generating regular expressions from user-provided test cases
grex is a library that is meant to simplify the often complicated and tedious task of creating regular expressions. It does so by automatically generating a single regular expression from user-provided test cases. The resulting expression is guaranteed to match the test cases which it was generated from. This project has started as a Rust port of the JavaScript tool regexgen written by Devon Govet
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
Skypack: search millions of open source JavaScript packages
How to Use Defaulthttps://cdn.skypack.dev/package-name https://cdn.skypack.dev/@scope/package-name Package Versionhttps://cdn.skypack.dev/preact@10 https://cdn.skypack.dev/preact@^10.5.0 https://cdn.skypack.dev/preact@10.5.5 Package Exporthttps://cdn.skypack.dev/preact/hooks https://cdn.skypack.dev/preact@^10.5.0/hooks Minified (?min)https://cdn.skypack.dev/preact?minDeno (?dts)https://cdn.skypack
node-ipcに悪意あるコードが含まれている問題について
node-ipcというnpmパッケージに悪意あるコードが含まれていた問題についてのメモ書きです。 2022-03-15に、node-ipcのメンテナーによって悪意あるコードを含むnode-ipcが公開されていた問題です。 問題のあるバージョン 9.2.2 unpublish済み Hidden functionality in node-ipc · GHSA-8gr3-2gjw-jj7g · GitHub Advisory Database 10.1.1, 10.1.2 unpublish済み Embedded Malicious Code in node-ipc · CVE-2022-23812 · GitHub Advisory Database 11.0.0+ node-ipc behavior change · GHSA-3mpp-xfvh-qh37 · GitHub Advisor
Makefileの代わりにnpm scripts+zxを使う - 詩と創作・思索のひろば
そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として Makefile を使いがち。 Pros make は事実上どんな環境にもあることを期待してよい シェルで実行されるコマンドをそのまま書ける タスクの依存関係が明示できる Cons make では positional arguments が使えない 少し複雑なことをしようとすると Makefile 専用の文法を覚える必要がある 現代では、ファイルベースのタスクの依存関係は make が発明されたころほどは必要ではない Docker とか Go とか Webpack がよしなにしてくれることが多い 例: docker compose のラッパー ちょっとしたコマンドのラッパーを書きたいことがある。Makefile を書きはじめたらすべてのエントリポイントを make にしたい。ということで、以下のような Make
corepack is 何?
追記: 2023-11-19 corepack v0.20.0 にて、CLI のコマンド体系が一新されて多少わかりやすくなりました (PR#291)。新しいコマンドは README を参照。 追記: 2022-02-03 Node.js v14.19.0 に corepack が標準バンドルされました。 corepack がバンドルされていない Node.js v12 系は 2022-04-30 に EOL を迎えるので、あと 3 ヶ月もすればアクティブな Node.js 環境には必ず corepack が揃っているという状態になりますね。引き続き experimental ステータスのままではありますが。 追記: 2021-09-08 Node.js v16.9.0 で corepack が標準バンドルされました。まだ experimental 扱いですが。 デフォルトでは yarn も
Corepack | Node.js v21.7.3 Documentation
Corepack is an experimental tool to help with managing versions of your package managers. It exposes binary proxies for each supported package manager that, when called, will identify whatever package manager is configured for the current project, download it if needed, and finally run it. Despite Corepack being distributed with default installs of Node.js, the package managers managed by Corepack
package.json やロックファイルによるパッケージの依存関係の管理 - 30歳からのプログラミング
この記事では、npm installやnpm ciを実行したときにどのようにパッケージがインストールされるのか、依存パッケージにバージョンのコンフリクトが発生した際にどのように処理されるのか、などを見ていく。必要に応じて Yarn での挙動にも触れる。 動作確認に使った npm のバージョンは6.14.5。Yarn は1.22.4。 特に npm はバージョンによって動作が大きく異なるので、注意する。 package-lock.json によるバージョンの固定 package.jsonだけではインストールするパッケージのバージョンを固定できず、package-lock.json（Yarn の場合はyarn.lock）によってバージョンを固定する。 多くの人が知っている話ではあるが、重要な機能なので改めて触れておく。 package.jsonのdependenciesやdevDependen
[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)
GitHub - pnpm/pnpm: Fast, disk space efficient package manager
pnpm uses a content-addressable filesystem to store all files from all module directories on a disk. When using npm, if you have 100 projects using lodash, you will have 100 copies of lodash on disk. With pnpm, lodash will be stored in a content-addressable storage, so: If you depend on different versions of lodash, only the files that differ are added to the store. If lodash has 100 files, and a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - antfu/ni: 💡 Use the right package manager
package-manager-best-practices/published/npm.md at main · ossf/package-manager-best-practices
GitHub - nodejs/undici: An HTTP/1.1 client, written from scratch for Node.js
GitHub - vercel/fetch: Opinionated `fetch` (with retrying and DNS caching) optimized for use with Node.js
GitHub - mapbox/polyline: polyline encoding and decoding in javascript
Open Source Insights