node腳本文件

㈠ node js-nodejs怎麼獲取腳本所在的路徑

nodejs提供了一個path的模塊，它提供了一系列的工具還是，用於處理文件和目錄的路徑。引入模塊：

constpath=require('path');

1、獲取一個文件的目錄名 path.dirname()

constfilepath='/tmp/demo/js/app.js';//腳本路徑
console.log(path.dirname(filepath));//輸出：/tmp/demo/js

2、獲取當前工作進程的目錄

console.log(process.cwd());

㈡ node.js是什麼

Node.js 是一個基於 Chrome V8 引擎的javaScript運行環境。 Node.js 使用了一個事件驅動、非阻塞式 I/O 的模型。

Node 是一個讓 JavaScript 運行在服務端的開發平台，它讓 JavaScript 成為與PHP、Python、Perl、Ruby等服務端語言平起平坐的腳本語言。發布於2009年5月，由Ryan Dahl開發，實質是對Chrome V8引擎進行了封裝。

Node對一些特殊用例進行優化，提供替代的API，使得V8在非瀏覽器環境下運行得更好。V8引擎執行Javascript的速度非常快，性能非常好。Node是一個基於Chrome JavaScript運行時建立的平台， 用於方便地搭建響應速度快、易於擴展的網路應用。Node 使用事件驅動， 非阻塞I/O模型而得以輕量和高效，非常適合在分布式設備上運行數據密集型的實時應用。

(2)node腳本文件擴展閱讀：

Node採用一系列「非阻塞」庫來支持事件循環的方式。本質上就是為文件系統、資料庫之類的資源提供介面。向文件系統發送一個請求時，無需等待硬碟（定址並檢索文件），硬碟准備好的時候非阻塞介面會通知Node。

該模型以可擴展的方式簡化了對慢資源的訪問， 直觀，易懂。尤其是對於熟悉onmouseover、onclick等DOM事件的用戶，更有一種似曾相識的感覺。

㈢ node 循環載入-

「循環載入」（circular dependency）指的是，a腳本的執行依賴b腳本，而b腳本的執行又依賴a腳本。

通常，「循環載入」表示存在強耦合，如果處理不好，還可能導致遞歸載入，使得程序無法執行，因此應該避免出現。

但是實際上，這是很難避免的，尤其是依賴關系復雜的大項目，很容易出現a依賴b，b依賴c，c又依賴a這樣的情況。這意味著，模塊載入機制必須考慮「循環載入」的情況。

對於 JavaScript 語言來說，目前最常見的兩種模塊格式 CommonJS 和 ES6，處理「循環載入」的方法是不一樣的，返回的結果也不一樣。

介紹 ES6 如何處理「循環載入」之前，先介紹目前最流行的 CommonJS 模塊格式的載入原理。

CommonJS 的一個模塊，就是一個腳本文件。require命令第一次載入該腳本，就會執行整個腳本，然後在內存生成一個對象。

上面代碼就是 Node 內部載入模塊後生成的一個對象。該對象的id屬性是模塊名，exports屬性是模塊輸出的各個介面，loaded屬性是一個布爾值，表示該模塊的腳本是否執行完畢。其他還有很多屬性，這里都省略了。

以後需要用到這個模塊的時候，就會到exports屬性上面取值。即使再次執行require命令，也不會再次執行該模塊，而是到緩存之中取值。也就是說，CommonJS 模塊無論載入多少次，都只會在第一次載入時運行一次，以後再載入，就返回第一次運行的結果，除非手動清除系統緩存。

CommonJS 模塊的重要特性是載入時執行，即腳本代碼在require的時候，就會全部執行。一旦出現某個模塊被"循環載入"，就只輸出已經執行的部分，還未執行的部分不會輸出。

讓我們來看，Node 官方文檔 裡面的例子。腳本文件a.js代碼如下。

上面代碼之中，a.js腳本先輸出一個done變數，然後載入另一個腳本文件b.js。注意，此時a.js代碼就停在這里，等待b.js執行完畢，再往下執行。

再看b.js的代碼。

上面代碼之中，b.js執行到第二行，就會去載入a.js，這時，就發生了「循環載入」。系統會去a.js模塊對應對象的exports屬性取值，可是因為a.js還沒有執行完，從exports屬性只能取回已經執行的部分，而不是最後的值。

a.js已經執行的部分，只有一行。

因此，對於b.js來說，它從a.js只輸入一個變數done，值為false。

然後，b.js接著往下執行，等到全部執行完畢，再把執行權交還給a.js。於是，a.js接著往下執行，直到執行完畢。我們寫一個腳本main.js，驗證這個過程。

執行main.js，運行結果如下。

上面的代碼證明了兩件事。一是，在b.js之中，a.js沒有執行完畢，只執行了第一行。二是，main.js執行到第二行時，不會再次執行b.js，而是輸出緩存的b.js的執行結果，即它的第四行。

總之，CommonJS 輸入的是被輸出值的拷貝，不是引用。

另外，由於 CommonJS 模塊遇到循環載入時，返回的是當前已經執行的部分的值，而不是代碼全部執行後的值，兩者可能會有差異。所以，輸入變數的時候，必須非常小心。

上面代碼中，如果發生循環載入，require('a').foo的值很可能後面會被改寫，改用require('a')會更保險一點。

ES6 處理「循環載入」與 CommonJS 有本質的不同。ES6 模塊是動態引用，如果使用import從一個模塊載入變數（即import foo from 'foo'），那些變數不會被緩存，而是成為一個指向被載入模塊的引用，需要開發者自己保證，真正取值的時候能夠取到值。

請看下面這個例子。

上面代碼中，a.mjs載入b.mjs，b.mjs又載入a.mjs，構成循環載入。執行a.mjs，結果如下。

上面代碼中，執行a.mjs以後會報錯，foo變數未定義，這是為什麼？

讓我們一行行來看，ES6 循環載入是怎麼處理的。首先，執行a.mjs以後，引擎發現它載入了b.mjs，因此會優先執行b.mjs，然後再執行a.mjs。接著，執行b.mjs的時候，已知它從a.mjs輸入了foo介面，這時不會去執行a.mjs，而是認為這個介面已經存在了，繼續往下執行。執行到第三行console.log(foo)的時候，才發現這個介面根本沒定義，因此報錯。

解決這個問題的方法，就是讓b.mjs運行的時候，foo已經有定義了。這可以通過將foo寫成函數來解決。

這時再執行a.mjs就可以得到預期結果。

這是因為函數具有提升作用，在執行import {bar} from './b'時，函數foo就已經有定義了，所以b.mjs載入的時候不會報錯。這也意味著，如果把函數foo改寫成函數表達式，也會報錯。

上面代碼的第四行，改成了函數表達式，就不具有提升作用，執行就會報錯。

我們再來看 ES6 模塊載入器SystemJS給出的一個例子。

上面代碼中，even.js裡面的函數even有一個參數n，只要不等於 0，就會減去 1，傳入載入的odd()。odd.js也會做類似操作。

運行上面這段代碼，結果如下。

上面代碼中，參數n從 10 變為 0 的過程中，even()一共會執行 6 次，所以變數counter等於 6。第二次調用even()時，參數n從 20 變為 0，even()一共會執行 11 次，加上前面的 6 次，所以變數counter等於 17。

這個例子要是改寫成 CommonJS，就根本無法執行，會報錯。

上面代碼中，even.js載入odd.js，而odd.js又去載入even.js，形成「循環載入」。這時，執行引擎就會輸出even.js已經執行的部分（不存在任何結果），所以在odd.js之中，變數even等於undefined，等到後面調用even(n - 1)就會報錯。

㈣ 怎麼執行node app.js 腳本

1、直接運行run.bat文件
下面的內容為批處理文件run.bat中的內容，批處理命令中NODE_PATH為Node.js的安裝路徑。使用express 生成的項目。app.js為待測試的Node.js 文件。
@set NODE_PATH=D:\nodejs\demo\npm
@echo %PATH% | find "Node.js"
@if %errorlevel% == 1 set PATH=%PATH%;%NODE_PATH%
@rem @echo %cd%
@node app.js
2、通過參數運行run.bat文件
批處理文件僅起到設置環境變數的作用，在Node.js項目的目錄下運行。批處理文件命令為：
@set NODE_PATH=D:\nodejs\demo\npm
@echo %PATH% | find "Node.js"
@if %errorlevel% == 1 set PATH=%PATH%;%NODE_PATH%
@rem @echo %cd%
@node %1
例如：
D:\nodejs\demo\>node app.js

㈤ node js-nodejs怎麼獲取腳本所在的路徑

nodejs提供了一個path的模塊，它提供了一系列的工具還是，用於處理文件和目錄的路徑。引入模塊：

const path = require('path');

1、獲取一個文件的目錄名 path.dirname()

const filepath = '/tmp/demo/js/app.js'; // 腳本路徑console.log(path.dirname(filepath)); // 輸出：/tmp/demo/js

2、獲取當前工作進程的目錄

console.log(process.cwd());

㈥ 如何在nodejs里調用執行系統命令

NodeJS 子進程提供了與系統交互的重要介面，其主要 API 有：
標准輸入、標准輸出及標准錯誤輸出的介面
child.stdin 獲取標准輸入
child.stdout 獲取標准輸出
child.stderr 獲取標准錯誤輸出
獲取子進程的PID：child.pid
提供生成子進程的方法：child_process.spawn(cmd, args=[], [options])
提供直接執行系統命令的方法：child_process.exec(cmd, [options], callback)
提供調用腳本文件的方法：child_process.execFile(file, [args], [options], [callback])
提供殺死進程的方法：child.kill(signal='SIGTERM')

㈦ node.js腳本問題

你確定能執行？
var player = require("./player.js");
player就是 player_enter 函數
你要 player(2,"玩家2") 這樣才對
player.player_enter 是undefined，應該報錯了吧

㈧ 如何用node寫一個腳本

是可以的，node.js是一個伺服器端運行JavaScript腳本的環境,這個環境下保持了客戶端JavaScript的api一致,並且強制使用單進程單線程模式下工作的方式也與運行在瀏覽器宿主下的javascript保持一致,看似沒有其他伺服器端語言的任何優勢,錯了,上面提到的單進程單線程模式其實就是它的一大優點.

㈨ 手把手教你使用nodejs編寫cli(命令行)

前端日常開發中，會遇見各種各樣的cli，比如一行命令幫你打包的webpack，一行命令幫你生成vue項目模板的vue-cli，還有創建react項目的create-react-app等等等等。這些工具極大地方便了我們的日常工作，讓計算機自己去干繁瑣的工作，而我們，就可以節省出大量的時間用於學習、交流、開發、 逛steam 。

但是有時候一些十分特別的需求，我們是找不到適合的cli工具去做的。比如說，你的項目十分龐大，你給項目添加一個新的路由，要經過 創建目錄 -> 創建.vue文件 -> 更新vue-router的路由列表 這一趟流程，就算快捷鍵創建目錄文件用得再熟悉，也比不過你一行命令來得快，特別是路由目錄嵌套深，.vue文件初始化模板復雜的時候。

所以呢，何不為自己項目寫一個cli？就專門做這些繁瑣的活？

nodejs的cli，本質就是跑node腳本嘛，基本上每位前端er都會：

然後命令行調用

可以做得更逼真一點，我們在package.json裡面的scripts欄位上添加一下腳本名：

然後命令行調用：

但是，看到這里你肯定會說，人家webpack還有vue-cli都是「有名字」的！什麼 vue-cli init app 、 webpack -p 的，多漂亮，看看這個命令行， node index.js ，還 npm run hello ，誰不會啊，丑不拉幾的，怕又不是來水文章的哦？差評！！

別急啊各位大人，接下來就說說，如何給這個node腳本起個名字。

姑且，先把這個cli的名字命名為 hello-cli ，就是我們能夠在命令行裡面，輸入 hello-cli ，然後它就列印一句 hello world ，沒有 node 也沒有 npm ，就是：

這樣，你的第一個cli腳本就成功安裝了，可以在命令行裡面，直接敲你的cli名字，看看結果輸出吧。

另外，如果你僅希望你的cli腳本僅在項目里執行，則需要在你項目裡面新建一個目錄，重復上述的操作，只是在第三步的時候，不要llink到全局裡面去，而是使用 npm i -D file:<你的腳本cli目錄路徑> ，把它當成項目的依賴安裝到node_moles裡面去，如果安裝成功，那麼在項目的package.json你會看到多了一條依賴，這條依賴的值不是版本號，而是你腳本的路徑。然後在node_moles裡面會有一個.bin目錄，裡面就存放著你的可執行文件。

當然，這樣安裝的cli腳本，必須在項目的package.json的scripts欄位上聲明腳本命令，然後通過 npm run 的方式執行。

哦？這樣子使用的話不就回到最最最開始的時候那種原始的 npm run hello 一樣么。

是的，但是有質的區別。使用 node index.js 這種方式調用的話固然簡單靈活，但是嚴重依賴腳本路徑，一旦目錄結構發生變動，寫在scripts的命令就要更改一次；但是使用npm安裝之後，本地的cli腳本就被拉到node_moles裡面，目錄結構變動對其影響不大。其次是不利於分享與發布，如果你想把你的cli腳本發布出去，那麼有一個好聽響亮的名字，比起在說明文檔裡面告訴使用者如何找到你的腳本路徑再用node執行它，簡直好上那麼一萬倍不是么？

這里也給我們提供了一個cli開發流程思路：

名字有了，輸出也有了，看看我們跟那些大名鼎鼎的cli工具，在形式上還差點啥？對了，人家可以支持不同參數選項的，還可以根據輸入的不同，產生不同的結果。

這樣吧，我們給這個cli加一個功能，既然叫 hello-cli ，那不能只會 hello world 吧，必須要見誰就說 hello 才行：

雖然這個功能很簡單，但是至少也是實現了「根據輸入的不同，產生不同結果」的效果。

命令行上的參數，可以通過 process 這個變數獲取， process 是一個全局對象而不是一個包，不需要通過 require 引入。通過 process 這個對象我們可以拿到當前腳本執行環境等一系列信息，其中就包括命令行的輸入情況，這個信息，保存在 process.argv 這個屬性里。我們可以列印一下：

列印結果：

可以看出，argv是個數組，前兩位是固定的，分別是node程序的路徑和腳本存放的位置，從第三位開始才是額外輸入的內容。那麼實現上面的功能就很簡單了，只要讀取argv數組的第三位，然後輸出出來就可以了。

npm社區中也有一些優秀的命令行參數解析包，比如 yargs ,tj的 commander.js 等等

如果你想使用比較復雜的參數或者命令，建議還是用第三方包比較好，手寫解析太耗精力了。

現在，你可以自由自在的寫你自己的cli腳本了。
如果你希望寫一個項目打完包自動推上git的cli，或者自動從git倉庫裡面拉取項目啟動模板，那麼，你需要通過node的 child_process 模塊開啟子進程，在子進程內調用git命令：

不僅是git命令，包括系統命令、其他cli命令都可以在這里執行。特別是系統命令，使用系統命令對文件目錄進行操作，效率比fs高到不知道哪裡去了。

社區上也有一些不錯的包，比如阮一峰老師推薦的 shelljs

如果你不那麼希望你的cli用起來那麼「硬核」，希望更人性化一點，比如提供一些友好的輸入、提示啊，給你的輸出加點顏色區分重點啊，寫個簡單的進度條啊等等，那麼你就需要美化一下你的輸出了。

除了顏色這部分，不使用第三方包實現起來非常繁瑣復雜，其他的功能，都可以試試自己寫。
顏色部分使用了第三方包 colors ，這里就不演示了。
其他都是由nodejs自帶的 readline 模塊實現的。

繪制的思路跟canvas繪制動畫一樣，只不過canvas是清除畫布，而命令行這里是通過 readline.clearScreenDown 清除輸出。

這樣，一個簡易的，人性化的，帶點點進度條動畫的命令行cli工具就寫好了，你也可以發揮你的想像力，去寫一些更有趣的效果出來。

畢竟我們前端，有瀏覽器我們可以寫動畫，沒了瀏覽器我們一樣可以寫動畫。