摘要：前言記錄下開發(fā)的一些事，加強(qiáng)自己對的應(yīng)用。雛形參考于的項(xiàng)目管理，發(fā)現(xiàn)非常的優(yōu)雅。嘗試通過修改權(quán)限為，最后無果不了了之。方式二詢問篩選會(huì)在終端監(jiān)聽輸入的關(guān)鍵字，根據(jù)關(guān)鍵字篩選出一系列的倉庫。自己也在使用，打算長期維護(hù)。

記錄下開發(fā)的一些事，加強(qiáng)自己對nodejs的應(yīng)用。共勉！

對于經(jīng)常參與開源貢獻(xiàn)，或者看見某些庫，像試試手的人來說，經(jīng)常需要git clone https://xxxx

操蛋的是，程序員是懶的，一般不會(huì)手動(dòng)去刪除某個(gè)項(xiàng)目，導(dǎo)致于克隆的項(xiàng)目會(huì)越來越多。

對于這些項(xiàng)目的管理，則會(huì)變得越來越困難，放眼放去，全是文件夾。

所以，需求就誕生了。

參考于GO的項(xiàng)目管理，發(fā)現(xiàn)非常的優(yōu)雅。

GO的項(xiàng)目類似的結(jié)構(gòu)是這樣的

https://{source}/{owner}/{name}

- source
    - owner
        - name
        - name
    - owner
        - name
        - name
        - name
- source
    - owner
        - name
        - name

所以就想著寫一個(gè)功能與之類似的。

這樣基本就確定了一個(gè)項(xiàng)目目錄的唯一性。

簡單無腦，我只管克隆，卻不用管克隆的項(xiàng)目在哪個(gè)文件夾，想刪就刪。

于是，雛形git-clone-cli就誕生了

這只是一個(gè)簡單的，代替git clone xxx的工具

隨著需求越來越多，已經(jīng)不能滿足簡單的git clone了，所以gpm來了

相對與git clone, 豐富了一些東西，更另我們方便管理

支持克隆Github, Gitlab等等

多樣的命令，比如list，find，clean，relink，import

支持插件，配置文件，hook

> 舉個(gè)簡單的例子，克隆一個(gè)Javascript項(xiàng)目，克隆之后，自動(dòng)運(yùn)行 npm install 或 yarn
> 想要什么樣的插件，什么用的hook，隨你配置

FIX ME : Windows下，如果克隆到一半，手動(dòng)中斷進(jìn)程，則克隆下來的項(xiàng)目是只讀，無法修改，無法刪除。
嘗試通過node修改權(quán)限為777，最后無果, 不了了之。

這樣會(huì)導(dǎo)致一些命令因?yàn)闆]有權(quán)限而失敗

交互方式的選擇一直是我蛋疼的問題，又要兼容多平臺(tái)，又要簡單優(yōu)雅。

比如 gpm find，搜索某個(gè)倉庫，然后獲取相應(yīng)的信息

方式一：輸入(半)全稱

gpm find @gpmer/gpm.js

優(yōu)點(diǎn)：

幾乎能精準(zhǔn)搜索

跨終端兼容性好

缺點(diǎn)：

太繁瑣，除了自己的庫，其他人的庫我看并不記得。

方式二：詢問/篩選

gpm find

會(huì)在終端監(jiān)聽輸入的關(guān)鍵字，根據(jù)關(guān)鍵字篩選出一系列的倉庫。
然后通過上下箭頭，選擇倉庫

優(yōu)點(diǎn)：

沒必要輸入繁瑣的關(guān)鍵字，只需要記得大概

缺點(diǎn)：

有兼容性問題，linux和OS X下沒有問題，Windows下兼容pwoerShell和cmd，但是不兼容git bash

Linux和OS X都是unix形式的路徑, 在gpm add xxx, 可以直接復(fù)制路徑, cd到對應(yīng)的目錄.

Windows下, 獲取到的是Windows風(fēng)格的路徑, 如果你在使用Git Bash. 很顯然是不能cd的.

折中方案是加個(gè)-u, --unix參數(shù), 選擇輸出unix的路徑

在nodejs里面, 無論怎么改變工作目錄, 也只是改變了這個(gè)(子)進(jìn)程的工作目錄. 沒法改變所使用的終端的工作目錄.

后來終于發(fā)現(xiàn)了robotjs自動(dòng)化工具.

可以在終端輸入命令, 然后Enter.

可惜的是, 又是Windows不兼容. 而且robotjs的包還不小, 對于頻繁升級(jí)是一種負(fù)擔(dān).

所幸就放棄了自動(dòng)cd到工作目錄的念頭

FIX ME: 添加了插件機(jī)制，豐富了一些功能。克隆之后，自動(dòng)運(yùn)行 npm install 或 yarn。
只需要在命令后面加個(gè)參數(shù): gpm add xxx -p <插件名>
要引用全局插件，就必須要知道npm的全局node_modules在哪里。
很遺憾的是，Windows下，獲取到的位置不正確，導(dǎo)致插件不能正常調(diào)用。

你可以在你的項(xiàng)目創(chuàng)建一個(gè).gpmrc配置文件，里面寫一些hook，比如：

{
  "hooks":{
    "add": "npm install"
  }
}

當(dāng)通過gpm添加這個(gè)項(xiàng)目之后，則運(yùn)行hooks里面對應(yīng)的shell。

FIX ME 問題就在于這個(gè)shell，并不安全。如果要是rm -rf /，恰巧又以root權(quán)限運(yùn)行，那就悲劇了。

還有就是多重的shell，比如npm install && npm run build怎么去運(yùn)行。

這不是很簡單? 直接 exec("npm isntall && npm run build")就完事了啊

NO, NO, NO. exec()并不優(yōu)雅而且還有限制，我更喜歡用spawn

但是spawn("npm", "isntall && npm run build".split(" "))這樣是會(huì)報(bào)錯(cuò)的. && 不是有效的命令

實(shí)際上我是這么做的，上面的命令拆分成為兩條spawn("npm", ["isntall"])和spawn("npm", ["run", "build"])

你可能已經(jīng)在~/project/這個(gè)目錄下存放了很多的項(xiàng)目。如果要讓你重新gpm add xxxx一個(gè)一個(gè)的添加進(jìn)來，你愿意嗎？

程序員要偷懶，所以才有import這個(gè)命令。把已存在的項(xiàng)目，按照source > owner > name的目錄結(jié)構(gòu)擺放好。

這又涉及到一個(gè)問題。我又想導(dǎo)入，又不想破壞原來~/project/的結(jié)構(gòu)，這個(gè)時(shí)候就用到link。

在對應(yīng)的source > owner > name目錄下，創(chuàng)建一個(gè)link，指向~/project/中的項(xiàng)目

問題就來了，當(dāng)你要?jiǎng)h除這個(gè)項(xiàng)目的時(shí)候，即刪除source > owner > name,會(huì)報(bào)錯(cuò)。link文件需要解除link才能刪除

有找過類似mock文件系統(tǒng)的方案，但是都感覺不太優(yōu)雅。

某天突然頓悟，為什么還有模擬什么文件系統(tǒng)呢，為什么就不能用真實(shí)的呢，臨時(shí)創(chuàng)建一個(gè)目錄，在這個(gè)目錄底下完整地走一遍流程，然后再對比預(yù)期，這樣不就好了嗎

從開始寫，到現(xiàn)在，commit有差不多300多次，前前后后一個(gè)多月，也一直是我一個(gè)人使用，我個(gè)人也覺得比較好用(好過沒有，逃...)

總感覺還有很多不完善的地方，但是個(gè)人能力和想法都有限，只能慢慢的完善。自己也在使用，打算長期維護(hù)。

最后給上項(xiàng)目地址：gpmer/gpm.js

我只是個(gè)菜雞 XD，希望有大牛給個(gè)PR或者給一些建議