npm

我收到了這個問題： 每次運行 npm run dev時，我得到的本地主機端口都不一樣。一開始是 3000，然後再次運行又得到了 3001，再次運行又得到了 3002。我們怎麼強制它使用 3000 端口？ 在本地開發網站時，你可以使用 npm run dev 命令來啟動開發伺服器。 這是 Web 開發 中的常見做法，所有工具似乎都會使用這個程式，例如 Astro 和 Next.js 等等。 每次運行這個命令時，它都是一個長時間執行的進程，不會自動結束。 例如你運行 Astro 的開發伺服器，它會在 3000 端口上監聽： 然後你打開另一個終端，再次運行 npm run dev，這次它會在 3001 端口上運行： 現在你的應用程式同時在以下兩個地址上運行： http://localhost:3000 和 http://localhost:3001 你需要在終端中使用 ctrl-c 結束這兩個進程，以確保 3000 端口不被佔用，且在你嘗試打開 http://localhost:3000 時瀏覽器中不會顯示任何內容。 然後你可以再次運行 npm run dev，它會自動在空閒的 3000 端口上啟動。 每當你對項目進行更改（例如因為需要 npm install 某個套件），你需要使用 ctrl-c 結束開發伺服器，然後重新啟動它。

回顧過去十年的JavaScript和Web的發展，真是一段驚心動魄的旅程。 儘管我書架上有一些1998年的JS書籍，但2010年時我並沒有寫很多JavaScript。當時我主要使用Mootools和jQuery插件。可能有些JS代碼是我寫的，但並沒有什麼突破性的創新。 那時的JavaScript絕對不被視為熱門語言。它的主要用途是在像GMail、Google Maps等有大量預算的項目中進行一些高級工作。 對於大多數人來說，用JavaScript編寫整個應用程序的概念當然是陌生的。 快進到2019年12月31日，JavaScript可真是太普遍了。 JavaScript無所不在。在過去的10年中，它經歷了多次更新，包括一個主要更新（ES6），如今我們寫JavaScript的方式與2010年完全不同。 異步和等待、箭頭函數、Promises、生成器、const/let、類、模板字面量等，肯定使現代JavaScript看起來和行為也非常不同。 ES模塊使大型應用程式更易於撰寫和維護。 但這不僅僅是語法和語言的新特性改變了。 我認為，這十年最大的變化之一就是構建工具的引入和廣泛使用。從Grunt到Gulp再到Webpack、Parcel和Rollup，工具的發展如此迅速，作為開發者，我們每天都有越來越大的能力。 模塊打包器為我們提供了非常高級的功能，如樹搖篩檢。了解這些技術是如何從早期發展至今真是令人驚嘆。 我們要提到Node.js嗎？從技術上講，Node在2009年春季首次推出，所以並不屬於這個十年。但可以肯定的是，Node第一年並沒有取得很大的突破，但在這十年中卻取得了巨大的成功。 現在讓我們來談談瀏覽器。2010年1月的IE版本是8，其佔有率超過50%並且Edge還不存在。Chrome作為一歲的瀏覽器佔有率僅為5%，因為1.0版本是在2008年12月發布的。你能想像嗎？如今Chrome是最受歡迎的瀏覽器，遠超其他瀏覽器。據我所知，64%的互聯網使用Chrome，而Safari佔有16%。 說到Safari，在2010年1月，iPhone 3GS已經推出（我當時沒有，我還用著Nokia。我第一部iPhone是在那一年晚些時候推出的iPhone 4）。那時JavaScript在該設備上執行速度可能不會很快。但如今移動瀏覽器可以以閃電般的速度執行JavaScript，並且JavaScript被用於使用Cordova、Ionic、React Native等令人驚嘆的框架來構建移動應用程序。 npm於2010年1月推出，它的崛起可謂驚人。起初它只是一個Node.js模塊的包管理器，如今npm也成為了前端開發的事實標準。它在去年6月份超過了一百萬個包，我敢肯定它是世界上最大的軟件目錄。 順帶一提，GitHub在2010年1月剛剛存在1年半的時間。看看它當時的樣子真是有趣。 在這十年中，許多驚人的項目應運而生。我可以提到Ember.js、CoffeeScript、Angular、React，只舉幾個例子。 我有幸參與並加入了許多不同的社區，而JavaScript和整個生態系統之所以在這十年中發展如此迅速，是因為工作在其中的人們。 憑著熱情、勤奮、承諾和慷慨精神，開源社區以及成百上千的充滿企圖心的公司，使JavaScript這個開發世界的一角成為今天的模樣。 回顧過去，看到我們走了多遠真是令人愉悅。 我真的無法想像這個未來十年會帶給我們什麼。

關於 node_modules 資料夾大小辯論的我的想法 我曾對於 node_modules 資料夾的大小感到懊惱。一個 JavaScript 應用程式怎麼可能在沒有我加入任何一行程式碼的情況下就有100、200MB的大小呢？我只是執行 npx create-react-app todolist，然後下載了218.7MB的東西！（我現在剛剛檢查了一下，這是真的數字）。 每當你思考 node_modules 的大小時，請想想我們程式開發人員投入的無數工時。 這是完全開源的軟體，是你可以檢視和學習的軟體。它是由世界各地的程式開發人員和公司慷慨捐贈的。它是一個全球性的努力，某人將它變得非常簡單好用。首先是 npm 這個工具，接著才是 npm 公司。 我們都同意將自己的程式碼發布到他們的伺服器上，人們在上面進一步建立了其他東西，直到我們得到了快速入門工具（如 create-react-app 或 Vue CLI 等），可以免費獲得大量功能。 在 TB 級快速儲存的時代，200MB 的大小算太大嗎？ 請記住，在這個大小中，絕大多數是測試、文件等等。而且剩下的程式碼絕大多數只會在開發環境中使用。這並不意味著你會將一個200MB的應用程式提供給用戶，我認為這一點是深入人心的。 我以 create-react-app 為例，那 200MB 中有些什麼？ 首先，create-react-app 包含了： 編譯器 (Babel) 打包工具 (Webpack) 程式碼壓縮工具 程式碼檢查工具 (ESLint) 樣式流程工具 (SCSS) 具有熱重載功能的開發伺服器 測試執行工具 (Jest) 如果你想要開發 Mac 或 iPhone 應用程式，你必須安裝蘋果提供的 IDE，即 Xcode。Xcode 的大小（等一下……）幾乎是 14GB。那是 node_modules 的 70 倍大小。確實，我們在比較兩件不同的事物，但 node_modules 包含了你開始編寫程式碼所需的一切。你可以搭配大小為 200MB 的 VS Code 或大小為 30MB 的 Sublime Text 使用，都沒關係，並不是必須的（而你卻無法在沒有 Xcode 的情況下創建 iOS/macOS 應用程式）。...

什麼時候一個 package 是一個依賴(dependency)，什麼時候是一個開發依賴(dev dependency)? 當你使用 npm install <package-name> 命令來安裝一個 npm package 時，你是將它安裝為一個 依賴(dependency)。 該 package 會自動列在 package.json 文件的 dependencies 列表中（自 npm 5 版本起：之前需要手動指定 --save）。 當你添加 -D 標誌或 --save-dev 時，你是將它安裝為一個開發依賴(dev dependency)，這會將它添加到 devDependencies 列表中。 開發依賴主要是一些僅用於開發的 package，在生產環境中是不需要的。例如測試 package、webpack 或 Babel。 當你進入生產環境時，如果目錄中有一個 package.json 文件，執行 npm install 就會安裝這些 package，因為 npm 假設這是一個開發佈署。 你需要設置 --production 標誌 (npm install --production) 來避免安裝這些開發依賴。

套件最適合全局安裝的時機是什麼？為什麼？ 本地套件和全局套件的主要區別如下： 本地套件 安裝在執行 npm install <package-name> 的目錄中，並且放置在該目錄下的 node_modules 文件夾中 全局套件 則放置在系統的一個統一場所（具體位置取決於你的配置），不論你在何處運行 npm install -g <package-name> 在你的代碼中，它們的引用方式是一樣的： require('package-name') 那麼什麼時候應該選擇哪種安裝方式呢？ 一般而言，所有套件都應該本地安裝。 這樣確保你的電腦中可以有數十個應用程序，每個應用程序都可以運行其所需的不同版本的每個套件。 如果更新一個全局套件，則會使所有專案都使用新的版本，在維護方面可能會帶來一些麻煩，因為某些套件可能與其他依賴關係不相容等等。 每個專案都有自己的本地版套件，即使看起來可能會浪費資源，但與可能產生的負面後果相比，這是微不足道的。 當一個套件提供一個可從 shell（CLI）執行的可執行命令且在多個專案中重複使用時，應該全局安裝該套件。 你也可以本地安裝可執行命令並使用 npx 執行它們，但有些套件最好還是全局安裝。 一些你可能已經全局安裝的流行套件示例包括： npm create-react-app vue-cli grunt-cli mocha react-native-cli gatsby-cli forever nodemon 你可能已經在你的系統上全局安裝了一些套件。你可以在命令行中運行以下命令來查看它們： npm list -g --depth 0

了解如何解決使用 npm 安裝套件時可能遇到的問題 我在我的編程訓練營中遇到一些學生遇到了這個問題，這是我從未注意到的。 這是由於在空文件夾中安裝套件時 npm 的行為所導致的。 我建議使用 npm install <套件名稱> 來安裝套件，比如： npm install my-prime 在一個空文件夾中安裝。 默認情況下，這會創建一個 package.json 文件，將套件作為依賴添加到其中，創建一個 package-lock.json 文件，並將套件安裝在 node_modules 文件夾中。 但是有一些人沒有看到這種情況發生。似乎什麼都沒發生。 事實上發生的是，他們在父文件夾中有一個 package.json 文件和一個 node_modules 文件夾。 也許不僅僅在父文件夾中，而是在更高的文件夾層級中。 也許他們在家目錄下運行了 npm install <套件> 但沒有意識到，可能是為了測試。 npm 會遍歷整個文件夾樹，檢查是否存在包含 package.json 文件或 node_modules 文件夾的文件夾。如果找到這樣的文件夾，則該文件夾將被視為運行 npm 命令的「當前目錄」。 來源 要解決這個問題，最好的解決方法是刪除父文件夾中的 package.json 和 node_modules 文件夾。 這可能是一個錯誤。 另外，您還可以在文件夾中運行 npm init -y 命令，以創建一個空白的 package.json 文件，然後重新運行 npm install <套件> 命令，這時將會按預期運行。

安裝舊版的 npm 套件 學習如何安裝舊版的 npm 套件，這將有助於解決相容性問題。 使用 @ 語法可以安裝舊版的 npm 套件： npm install <package>@<version> 範例： npm install cowsay 安裝 1.3.1 版本（此文章撰寫時）。 使用以下方式安裝 1.2.0 版本： npm install [[email protected]](/cdn-cgi/l/email-protection) 全域套件亦可使用相同方式安裝： npm install -g [[email protected]](/cdn-cgi/l/email-protection) 您可能也有興趣列出套件的所有舊版。可以使用 npm view <package> versions 命令來實現： ❯ npm view cowsay versions [ '1.0.0', '1.0.1', '1.0.2', '1.0.3', '1.1.0', '1.1.1', '1.1.2', '1.1.3', '1.1.4', '1.1.5', '1.1.6', '1.1.7', '1.1.8', '1.1.9', '1.2.0', '1.2.1', '1.3.0', '1.3.1' ]

如何找出npm安裝包的位置 如果您剛開始使用npm，可以閱讀npm指南，其中包含了很多基本細節。 當您使用npm（或yarn）安裝一個包時，可以執行兩種類型的安裝： 本地安裝 全域安裝 默認情況下，當您輸入npm install命令時，例如： npm install lodash 該包將安裝在當前檔案結構中的node_modules子文件夾下。 同時，npm還會在當前資料夾中的package.json文件的dependencies屬性中添加lodash項目。 使用-g標誌可以執行全域安裝： npm install -g lodash 當這種情況發生時，npm不會將該包安裝在本地文件夾中，而是使用全域位置。 具體在哪裡？ npm root -g命令將告訴您在您的機器上的正確位置。 在macOS或Linux中，該位置可能是/usr/local/lib/node_modules。在Windows中，它可能是C:\Users\YOU\AppData\Roaming\npm\node_modules 然而，如果您使用nvm來管理Node.js版本，該位置將不同。 例如，我使用nvm，我的包位置顯示為/Users/flavio/.nvm/versions/node/v8.9.0/lib/node_modules。

npx是一種非常酷的執行Node代碼的方式，提供了許多有用的功能。 在這篇文章中，我想介紹一個非常強大的命令，從2017年7月開始在npm的5.2版本中可用：npx。 如果你不想安裝npm，你可以單獨安裝npx套件 npx讓你執行使用Node編寫並通過npm註冊表發佈的代碼。 輕鬆運行本地命令 Node開發人員習慣將大多數可執行命令作為全局套件發佈，以便它們能夠在路徑中並立即執行。 這很痛苦，因為實際上你不能安裝不同版本的相同命令。 運行npx 命令名稱將自動在項目的node_modules文件夾中找到正確的命令引用，而無需知道確切的路徑，也無需將套件安裝為全局註冊。 無需安裝的命令執行 npm還有另一個很棒的功能，就是允許在不先安裝它們的情況下運行命令。 這非常有用，主要原因是： 你不需要安裝任何東西 你可以運行不同版本的相同命令，使用@version語法 使用npx的典型演示是通過cowsay命令。cowsay會打印一頭牛，說出你在命令中輸入的內容。例如： cowsay "Hello"將打印以下內容： ____ < Hello > -------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||-----w | || || 現在，如果你之前從npm全局安裝了cowsay命令，否則當你嘗試運行該命令時，將會出錯。 使用npx，你可以在本地執行該npm命令，而無需將其安裝： npx cowsay "Hello" 就能運行了。 現在這只是一個有趣但毫無用處的命令。其他場景包括： 使用vue CLI工具創建新應用程序並運行：npx vue create my-vue-app 使用create-react-app創建新的React應用程序：npx create-react-app my-react-app 等等。 一旦下載完成，下載的代碼將被刪除。 使用不同的Node版本運行代碼 使用@指定版本，並結合node npm套件來達到這個目的： npx [[email protected]](/cdn-cgi/l/email-protection) -v #v6.14.3 npx [[email protected]](/cdn-cgi/l/email-protection) -v #v8.11.3 這有助於避免像nvm或其他Node版本管理工具這樣的工具。 直接從URL運行任意代碼片段 npx並不限制你只能運行npm註冊表中發佈的套件。 你可以運行存儲在GitHub Gist中的代碼，例如： npx https://gist.github.com/zkat/4bc19503fe9e9309e2bfaa2c58074d32 當然，運行你無法控制的代碼時，你需要小心，因為偉大的力量伴隨著偉大的責任。

在安装 Node 包时，会自动生成 package-lock.json 文件。了解一下它是做什麽的吧！ 在版本5中，npm 引入了 package-lock.json 文件。 这是什麽？你可能已经了解 package.json 文件，它更常见也存在更久。 该文件的目标是跟踪安装的每个包的确切版本，以便产品在各个环境中可以完全复制，即使包被维护者更新。 这解决了 package.json 未解决的一个非常具体的问题。在 package.json 中，您可以使用语义化版本号（SemVer）表示想要升级到的版本类型（补丁或次要），例如： 如果您写~0.13.0，您只想更新补丁版本：0.13.1是可以的，但0.14.0就不可以了。 如果您写^0.13.0，您想更新补丁和次要版本：0.13.1，0.14.0等等。 如果您写0.13.0，那就是确切的版本，将始终使用。 您不会将 node_modules 文件夹提交到 Git 中，因为它通常非常庞大。当您在另一台机器上使用 npm install 命令复制项目时，如果您指定了~语法，并已发布了一个补丁版本，该版本将会被安装。对于^和次要版本也是一样。 如果您在示例中指定了确切版本，例如0.13.0，则不受此问题的影响。 也许是您，或者是另一个人试图在世界另一端运行 npm install 来初始化该项目。 因此，您的原始项目和新初始化的项目实际上是不同的。即使补丁或者次要版本不应该引入破坏性更改，但我们都知道错误可能（将）滑入其中。 package-lock.json文件将您当前已安装的每个包的版本确定下来，npm在运行 npm install 时将使用这些确切的版本。 这个概念并不新鲜，其他的编程语言的包管理工具（例如 PHP 中的 Composer）已经使用类似的系统多年了。 需要将 package-lock.json 文件提交到您的 Git 仓库中，以便其他人可以获取，如果项目是公开的或您有协作者，或者如果您使用 Git 作为部署的源。 当您运行 npm update 命令时，package-lock.json 文件中的依赖版本将会被更新。 一个示例 以下是在空文件夹中运行 npm install cowsay 后得到的 package-lock.json 文件的示例结构： { "requires": true, "lockfileVersion": 1, "dependencies": { "ansi-regex": { "version": "3....