タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
皆さんnpmパッケージのバージョンを上げるときにハマって依存地獄から抜けられなかったことはありませんか? 私はあります。 複雑怪奇な依存関係を調べてみようとnode_modulesを覗いてみて、そのカオスっぷりに臭いものに蓋をしたことはありませんか? 私はあります。 そこでnode_modules以下について調べてみたのですが、node_modulesにどんな問題点があって、npmやyarn, pnpmは何を目指していたのか時系列順に紐解いた方がわかりやすいことに気づきました。 ここでは初期のnpmが抱えていた問題から今に至るまでを順を追って説明します。 するとnode_modulesの仕組みの他に、各パッケージマネージャの方針の違いが見えてくるはずです。 初期の頃のnpm (~2015年以前) この頃はシンプルで、依存関係はそのままnode_modulesのディレクトリ構造に反映されてい
(Last Update: 2022/02/03) npm と yarn(v1) と pnpm (とyarn v2)の違いについて記述します。 Versions npm Yarn pnpm 各パッケージの特徴 npm npmはnpm社が提供する、JavaScriptパッケージマネージャーです。 npmというコマンドラインで動作するプログラムでパッケージを管理できます。いわばnpm公式のパッケージマネージャーとなります。 Windows等でインストールするとNode.jsに同梱されています。 Yarn Yarnはnpmより後発のJavaScriptパッケージマネージャーです。 元々、npmにはインストール時のパッケージバージョンの非再現性やパフォーマンス上の問題、セキュリティの問題が山積しており、それを解決するために開発がスタートしました。 いわば、サードパーティのnpmということになります
yarnはおわるのか 今までさんざんお世話になったyarnさんですが、だんだんおいていかれているらしい?ので、今自分が設計してて制作中のサービスを「pnpm」におきかえる実験をしました。 こうしたことはだいたい一筋縄でいかないことが多く、朝からいろいろ調査をしてなんとか立ち上げにこぎつけた感があるので、備忘録兼報告書として書き記しておきます。 yarnにするか、npmにするか、pnpmにするか? 気持ち的にはビアンカにするかフローラにするか論争に、デボラが加わってメッチャ強い感じ…w (最初見た時、ampmの仲間かなんかかと思ったけど、performant npmっていうやつなんだって。なんだ、結果npmか…) 環境 Mac M1 Venture13.1 react 18.2.0 next 13.0.7 node v16.19.0 Homebrew 3.6.18 yarn 1.22.19
$ 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
はじめに こんにちは。ドワンゴ教育事業でエンジニアをしているユーンです。 N予備校アプリケーションやその他複数のプロジェクトで pnpm を採用しました。pnpm とは何か、npm とどう違うのかというのを node_modules の構造を追いながら理解しつつ、教育事業での採用した結果についてお話します。 pnpm とは pnpm とは、npm や yarn とレイヤーを同じくするパッケージマネージャであり、サードパーティのものです。 pnpm.io pnpm は他のツールと比較して高速でありディスク効率が良いと謳っています。 その pnpm の最大の特徴は、 node_modules の構造にあります。 例えば npm では v3 からフラットな node_modules を使うようになっております。yarn もデフォルトでは同様にフラットな node_modules を提供しています
niという npm/yarn/pnpm/bun を同じコマンドでインストール/アンストールコマンドを実行できるツールがあります。 antfu/ni: 💡 Use the right package manager 仕組み的には、各パッケージのロックファイルやCorepackで決められたpackageManagerフィールドの値から、どのパッケージマネージャを使うかを判断しています。 たとえば、package-lock.jsonがあるプロジェクトなら npm を使ってるので、niコマンドは npm のコマンドを実行します。 また、packageManagerフィールドがyarn@<version>になっている場合は、niコマンドは yarn コマンドを実行します。 なぜこういうツールが必要になるかというと、npm や yarn などのパッケージマネージャは、それぞれのパッケージマネージャの
といいつつも、この機能自体は要オプションで v9.7 からありましたが、 v10 でオプション不要になったので、 GA の気持ちで紹介します。 結論 pnpm v10 以上がローカルにインストールされていれば、 packageManager field に pnpm が指定されているプロジェクトでは、そのプロジェクトの pnpm を使うようになります。 ただし、その pnpm 自体はどこかしらにインストールされている必要があり、一般的にはプロジェクトの devDependencies にインストールするものかと思われます。 やるべきこと ローカルの pnpm を v10 以上にする。 プロジェクトの devDependencies に、使いたいバージョンの pnpm をインストールする プロジェクトの packageManager field に 2 と同じバージョンの pnpm を定義す
~ 秋のエンジニア大交流会 & LT会!!~( https://devguil.connpass.com/event/290596/ )で発表したセッションのスライドです。 サンプルリポジトリ: https://github.com/MH4GF/pnpm-workspace-knowhow-sample
3行まとめ pnpm の --filter オプションにはパッケージ名だけでなく git の commit や branch も渡すことができる pnpm ls --filter をうまく使えば「main branch からの diff の影響を受けるパッケージ」の一覧を取り出せる ドキュメントや help をちゃんと見ると、意外と知らないことが書いてある モチベーション LayerX のバクラク事業部では Webapp(Web Frontend アプリケーション)のモノレポ化を進めており、1つのリポジトリに複数の Next.js アプリケーションが存在します。 そこで悩ましいのが CI でのテストなどの実行です。 そのまま全件実行すると時間が長くなっていく e.g. アプリAのコードしか変更してないのに、アプリBのテストも実行されてしまうと時間もお金も無駄にかかる 何もしないとプロダクト
Catalogs を使うモチベーション Catalogs のメリットについては、ドキュメントではざっくり以下の3点が挙げられています。 単一バージョンを維持できることで、パッケージの重複によるバグの発生を防ぐ pnpm-workspace.yml を編集するだけで依存関係のアップグレードが完了する 依存関係アップグレード時に package.json を編集しなくてよくなり、git でのコンフリクトを避けられる 筆者の環境では特に1つ目の、「パッケージの重複によるバグを防ぐ」というのが大きなモチベーションとなりました。 モノレポと共通パッケージとパッケージ重複 筆者の環境では一部の Web Frontend もモノレポで運用しており、そのなかで一部の共通実装はモノレポ内パッケージとして切り出されています。以下は架空の例ですが、おおまかにこのような構造となっています。 たとえば各 webap
JSer.info #664 - Rollup 4.0.0がリリースされました。 Release v4.0.0 · rollup/rollup Node.js 14/16のサポート終了、Acornの代わりにSWCをパーサに使うように変更されています。 SWC利用に伴うオプションの削除や非推奨なオプションの削除などが含まれています。 Viteの現在と今後についてがViteConfで発表されています。 動画: https://viteconf.org/23/replay/vite_keynote スライド: State of Vite (ViteConf 2023) ViteはDevビルドにesbuild、ProdビルドにRollupを使うためビルド結果に差異が出やすいなどの問題があります。 そのため、Rollup互換を意識したRolldownというBundlerをRustで開発するという話。
pnpm を触り始めた ちょっと前に npm のことを勉強したときに、ゆうくさんに pnpm のことを教えてもらって気になってたので、触り始めた。 bufferings.hatenablog.com pnpm はパッケージをグローバルストアに保存して、各プロジェクトの node_modules ではハードリンクを使用する。だから、ファイルをコピーしなくていいので容量もくわないし、インストールのスピードも速いのか。へー!便利。 ハードリンクを使用するので、プロジェクトとストアが同じディスクにないといけないことを頭の片隅に入れておこうかなってくらい。 ストアの中身 そのグローバルストアのデフォルトの場所は、macOS だと ~/Library/pnpm/store/v3。どんな風に保存されてるんだろう?と思ってのぞいてみたら、こんな感じになってた。途中で切ってるけど2文字のフォルダがたくさんあ
はじめに 皆さんはnpm, yarn, pnpmどのPackage Managerを使っていますか? yarnしか使わない!という方もいるかもしれませんが、pnpm評判いいみたいだし使ってみようかなとか、チーム開発では安定のnpmなんだよなとか、複数のPackage Managerを使用するケースって少なくないかと思います。 そういった場合、それぞれのコマンドを覚えるのも面倒ですし、プロジェクトに応じて頭の切り替えをしないといけないのは大変です。 本記事は、そういった悩みを解決する方法を紹介します。 ni niはnpm,yarn,pnpm,bunに対応していて、それぞれのlockfileを読み取って、適切なコマンドを実行してくれるPackage Managerです。 niのコマンドは短く、わかりやすいのですぐ覚えられると思います。 ちなみに、作者はVueやNuxt、Viteなどのコアチーム
新年早々Yarnを利用していた個人ブログのプロジェクトをpnpmに移行したので、その際の作業ログを記事にします。 個人ブログの技術構成 私の個人ブログは以下のような技術構成を取っています。 パッケージマネージャー: Yarn v1 フレームワーク: Next.js UIライブラリ: Chakra UI CI: GitHub Actions ホスティング: Vercel pnpm pnpmは速さや効率性、厳格さを特徴に掲げるNode.js向けのパッケージマネージャーです。 本記事ではその特徴の詳細について記載しないため、下記のような解説記事を参考ください。 pnpmへの移行動機 npmやYarnは使った経験がありましたがpnpmはなかったので、個人ブログのリポジトリを使って技術検証してみようと思ったのが最初の動機です。 また、最近プライベートで利用しているMacのストレージがカツカツになって
newmoでは、フロントエンド、バックエンド、iOSやAndroidなどのモバイルアプリをすべて同じリポジトリで管理するmonorepoを採用しています。 monorepoを採用することで、アプリケーション間で共通のコードを共有することができたり、CIの管理が楽になったり、他のチームのコードを見るのにわざわざリポジトリをcloneする必要がなくなります。 また、monorepoを採用することで、アプリケーションが利用しているパッケージ(ライブラリやツール)のバージョンを1つだけにするOne Version Ruleが実装できます。 One Version Rule One Version Ruleは、monorepo内のパッケージのパッケージのバージョンを1つだけにするルールです。 The One Version Rule | Google Open Source One Versio
これはなに pnpm をベースにして実践的な monorepo プロジェクトを構築するまでの手順をまとめたものです。アプリケーション開発の実務では長らく yarn を常用してきましたが、極端に攻めたアプローチをしなければ pnpm でも十分に実務に耐えられると実感しました。筆者が実務で求める要件は大まかに以下のとおりです。 monorepo をサポートしている プロジェクトルートからサブパッケージの npm scripts を直接実行できる GitHub Action / CircleCI が動作する Renovate のサポート対象に含まれる 本稿では備忘録代わりとしてその内容をご紹介します。 pnpm とは yarn 同様、npm の代替として開発されているサードパーティのパッケージマネージャーです。インストールの速さと(ディスクスペースの)効率性に主眼を置いています。 Next.js
まだパッケージマネージャーの打ち間違いで消耗してるの? 初手煽りタイトル失礼します。よだかと申します。 僕はフリーランスでいくつかプロジェクトをやらせてもらっているのですが、プロジェクトごとにパッケージマネージャーが違ったりします。 これがかなり辛く、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! とても強い思いから
JSer.info #720 - pnpm 10.0 RC 1がリリースされました。 Release pnpm 10.0 RC 1 · pnpm/pnpm インストールするパッケージのlifecycle scriptをデフォルトで実行しないように変更が含まれています。 パッケージのpostinstallなどのlifecycle scriptの実行を許可するにはpnpm.onlyBuiltDependenciesの設定にパッケージ名を追加する必要があります。 feat!: use an allow list of built dependencies by default by zkochan · Pull Request #8897 · pnpm/pnpm これは、rspack v1.1.7でパッケージがハイジャックされマルウェアを実行するlifecycle scriptが含まれていた問題
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 3者の公式 概要 3者ともJavascriptのパッケージマネージャー。 npm はNode.jsをインストールすれば一緒にインストールされる。 yarn: npmと互換性があり、npmで使用していたプロジェクト設定ファイル(package.json)がそのまま使える。 pnpm: 同じくnpmと互換性があり、ディスクスペースの使用量と速度が大幅に改善されている。 先に npmとyarnとpnpmの違い2021 からわかりやすい結論。 筆者のおすすめ 初心者、もしくは複数人開発であればnpm をおすすめします。 標準ツールのため、Nod
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
JSer.info #689 - Next.js 14.2がリリースされました。 Next.js 14.2 | Next.js Turbopack RCをリリース、Server/Client Components間のTree Shakingの対応、CSSの読み込み順の問題の修正などが行われています。 Client側のRouter Cacheの期間を設定するstaleTimesオプションの追加なども行われています。 Vite/Rollup互換のプラグインを扱えるビルドツールであるFarm 1.0がリリースされました。 Release 🚀 Farm v1.0 is released! · farm-fe/farm Rustで書かれていて、キャッシュを使ったIncremental Build、Lazy Compilation、モジュールをグループ化してbundleできるなどの特徴を持っています
JSer.info #552 - パッケージマネージャであるpnpm 6.12.9がリリースされました。 Release v6.12.0 · pnpm/pnpm pnpm 6.12.0ではpnpm env use --global 16.5.0のように、Node.jsをインストールするコマンドが追加されています。 pnpm自体をsingle binaryとして配布した場合に、Node.jsがグローバルにインストールされていない環境でもpnpmが利用できるようになります。 そのような場合に、pnpmでNode.jsをインストールするためにpnpm envが追加されています。 Using pnpm as a Node.js version manager · Discussion #3434 · pnpm/pnpm webpack 5.49.0がリリースされました。 Release v5.49
pnpm でパッケージにパッチを当てる 2023.07.01 `pnpm patch` コマンドを使うと、依存パッケージのコードを直接書き換えることができます。 pnpm patch コマンドを使うと、依存パッケージのコードを直接書き換えることができます。例えば依存パッケージにバグがあった場合、プルリクエストを送って修正を提案する方法が最適ですが、提案した修正がマージされるまでタイムラグがあるでしょう。今すぐにバグを回避したい場合には、一時的に依存パッケージを直接修正する方法を取ることになるでしょう。 ですが node_modules ディレクトリ中のソースコードに直接修正を加えると、新たなパッケージを追加する目的などで npm install コマンドを実行したタイミングで修正内容が消えてしまいます。また、一般的に node_modules ディレクトリは git の管理下に置かれていな
この記事について みなさん、こんちにちは。 好きな絶滅動物はアルゲンタヴィス。uttk です。 先日、zenn-editor の Monorepo 構成を Lerna から pnpm + Turborepo + lerna-lite に変えたので、この記事でその構成について解説していこうと思います 💪 なんで、その構成? zenn-editor では Lerna を使って Monorepo 環境を構築していましたが、実際に Lerna を使っている部分はビルド時とリリース時のみで、ほとんどの機能を使用していませんでした。また、yarn workspace も併用していたため、違う Monorepo ツールが二つ存在していて、それぞれの役割が( 個人的に )分かりにくい状況でした。 そのため、Lerna を使わずに pnpm が提供している workspace 機能に寄せる形で構築した結果
Motivation pnpm is more performant at fetching, resolving, and storing dependencies. My personal experience shows that in some projects pnpm can be approx. 10x time faster at resolving dependencies and up to 3x more efficient for disk usage. It is also easy to start using pnpm if you have used npm or yarn before because the CLI is very similar. https://pnpm.io/motivation Migration guide Step 1: In
JSer.info #590 - pnpm 7.0.0がリリースされました。 Release v7.0.0 · pnpm/pnpm コマンドラインフラグの変更やデフォルト値の変更などの破壊的な変更が中心となっています。 Node.js 12のサポート終了、root packageはpnpm -r execなどの対象からデフォルトで除外するように変更。--filterがglobをサポート、@types/*を自動的にhoistしないようになるといった変更が含まれています。 その他には、strict-peer-dependenciesがデフォルトで有効となる変更も含まれています。 Mocha 10.0.0がリリースされました。 Release v10.0.0 · mochajs/mocha こちらもサポート終了した機能を削除するといった破壊的な変更が中心となっています。 Node.js 12のサ
JSer.info #699 - esbuild v0.22.0 がリリースされました。 Release v0.22.0 · evanw/esbuild Release v0.23.0 · evanw/esbuild v0.22 では--platform=nodeを指定した時に--package=externalをデフォルトにする変更を行いましたが、AWS CDK などが0.xの最新をインストールする仕組みなっていて問題が起きたため 0.23.0 では元の挙動へと revert されています。(AWS CDK 側も修正されています) また、Windows7,8 など古い OS のサポート終了、es2024のサポート、@esbuild/wasi-preview1パッケージの公開など Node.js v22.4.0 がリリースされました。 Release 2024-07-02, Version
はじめに 初心者フロントエンドエンジニアをしているRimlと申します。 お久しぶりです。 ふと弊社の分報SlackチャンネルでPlaywrightの話題が上がり、個人的に触れてたのでその知見や溜め込んでた記事は共有したのですが、どうせなら自分の関わってるプロダクトに導入すればいいじゃん!という流れから勝手ながら改善活動として環境構築の方をしました。 何気なくツイートしたら反応がちょっとあった(?) のもあり備忘録にでもなったらいいなと言うことで今回投稿させていただきました! E2Eテストはローカル環境で行わないためリポジトリを分けて構築します。 注意書き 以下環境にて構築、動作するものを前提にしています。 それぞれ違うものは置き換えて読み進めていただけると幸いです。 環境 MacOS Ventura 13 VSCode Gitlab Runner(Ubuntu 22.04.2 LTS) N
JSer.info #637 - Safari 16.4がリリースされました。 WebKit Features in Safari 16.4 | WebKit Safari 16.4 Release Notes | Apple Developer Documentation Beta版時の2023-02-20のJS: Sandpack 2.0、Safari 16.4 Beta、Reactドキュメンタリー - JSer.infoでも紹介しましたが、大量の変更点が含まれています。 margin-trimプロパティ、lh unit、CSS Typed Object Model APIのサポート、Constructable Stylesheetsのサポート Declarative Shadow DOM、EmentInternals、Imperative Slot APIのサポート RegExp l
Yarn 3.1 🎃👻 Corepack, ESM, pnpm, Optional Packages ... Welcome to the release notes for Yarn 3.1! We're quite excited by this release, as it brings various improvements that we've all been looking forward to. Let's dig into that! As always, keep in mind those are only the highlights, the full changelog is much more comprehensive. And if you just happen to love reading our release posts, here are
pnpm link behavior updated: The pnpm link command now adds overrides to the root package.json. In a workspace: The override is added to the root of the workspace, linking the dependency to all projects in the workspace. Global linking: To link a package globally, run pnpm link from the package’s directory. Previously, you needed to use pnpm link -g. Related PR: #8653 Secure hashing with SHA256: Va
pnpm の新規ユーザーから、pnpm が生成する node_modules の奇妙な構造についてよく聞かれます。 なぜ平坦な構造を使用しないのでしょうか。 依存のさらにその依存はどこにあるのでしょうか。 この記事では、npm や Yarn の生成するフラットな node_modules に馴染みのある読者を想定しています。 npm が v3 からフラットな node_modules を採用する必要があった理由については、 なぜ pnpm が必要なのでしょうか (英語) を参照してください。 では、なぜ pnpm は通常とは異なる構造の node_modules を使用するのでしょう。 試しに 2 つのディレクトリを作成して、片方には npm add express を、もう一方には pnpm add express を実行してみてください。 npm の方のディレクトリにある node_m
We are excited to announce the latest release of pnpm! To install it, check the installation page. Major Changes Node.js 14 Support Discontinued If you still require Node.js 14, don't worry. We ship pnpm bundled with Node.js. This means that regardless of which Node.js version you've installed, pnpm will operate using the necessary Node.js runtime. For this to work you need to install pnpm either
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く