因爲以前沒有真正地瞭解cnpm致使最近踩了個坑:cnpm兩種使用方式存在本質區別html
所以作個學習記錄,對學習到的相關知識點也作個概括總結。node
npm(node package manager)nodejs包管理器, 安裝、共享、分發代碼,管理項目依賴關係。默認源爲 registry.npmjs.org。 npm官網、 npm中文文檔。git
因爲npm默認源服務器在國外,國內訪問較慢且不穩定,淘寶作了一個完整 npmjs.org 鏡像cnpm, 同步頻率目前爲10分鐘一次。源爲 registry.npm.taobao.org。 cnpm文檔github
package-lock.json的做用是 鎖定版本。官方文檔shell
npm install(npm版本大於v5.0.0)時,npm
package-lock.json準確的描述了當前項目npm包的依賴樹,保證不一樣環境,不一樣時間下的依賴是同樣的。package-lock.json文件中記錄了下載源地址,能夠加快install速度。json
既然鎖定了版本,存在package-lock.json時,每次npm install仍是會被改動,緣由是:windows
項目的依賴版本依然是被鎖定,即便是小版本也不會更新,可是依賴的依賴並無被鎖定,所以會發現package-lock.json僅僅是修改了一些依賴的依賴,項目的依賴的版本並不會被修改緩存
而定製cnpm(非alias)在安裝依賴時,會無視package-lock.json文件。 cnpm核心模塊 npminstall
做者在《爲何我不使用 shrinkwrap(lock)》中解釋了這麼作的理由:bash
經過 semver 依賴機制,在一個良性的環境中,能夠快速的正向傳遞新功能和 bug fix,而 shrinkwrap(lock)就是這個傳遞路徑上的一道牆,雖然它也許能夠擋住一些新 bug 的引入,但實際上是得不償失的。咱們真正要作的是提供一個更好的環境(依賴可靠的模塊)。
究竟是選用semver依賴機制仍是shrinkwrap,業界內互不相讓,但我相信重要的不是哪一種方式的好與壞,而是業務方的使用姿式正確。
cnpm文檔中介紹了cnpm兩種使用方式:
$ npm install -g cnpm --registry=https://registry.npm.taobao.org
複製代碼
alias cnpm="npm --registry=https://registry.npm.taobao.org \ --cache=$HOME/.npm/.cache/cnpm \ --disturl=https://npm.taobao.org/dist \ --userconfig=$HOME/.cnpmrc"
複製代碼
天真我本來覺得, 這兩種使用方式並無區別。後來我發現我錯了,錯的一塌糊塗~
第二種alias方式僅僅只是將registry源切換,且使用特定的cache、distur、userconfig等,但實際仍是走npm,依賴安裝策略仍是走semver 依賴機制而不是cnpm的shrinkwrap(lock)。
所以,若工程的package-lock.json並無被ignore,將會出現問題:
A同窗本地使用alias cnpm,本地版本將會永遠鎖定;B同窗本地使用定製cnpm,
假設該工程的某一個依賴沒有遵循semver規範,小版本更新並無兼容,所以會致使使用定製cnpm的B同窗本地開發出現問題,而A同窗是OK的。
npm install,或者 npm i ,一般是用來安裝依賴項:
使用 npm ci ,會發生:
pnpm,採用了一種巧妙的方法,利用硬連接和符號連接來避免複製全部本地緩存源文件。Why should we use pnpm?
cnpm,國產,核心模塊 npminstall
介紹:
This project is inspired by pnpm, and has a similar store structure like pnpm. You can read pnpm vs npm to see the different with npm.
yarn,優勢 npm和yarn的區別,咱們該如何選擇?
npm:大家牛逼
快速切換npm registry源地址的工具。
NPM registry manager, fast switch between different registries: npm, cnpm, nj, taobao
Node版本管理工具。
nvm is a version manager for node.js, designed to be installed per-user, and invoked per-shell. nvm works on any POSIX-compliant shell (sh, dash, ksh, zsh, bash), in particular on these platforms: unix, macOS, and windows WSL.