摘要：前言記錄下開發的一些事，加強自己對的應用。雛形參考于的項目管理，發現非常的優雅。嘗試通過修改權限為，最后無果不了了之。方式二詢問篩選會在終端監聽輸入的關鍵字，根據關鍵字篩選出一系列的倉庫。自己也在使用，打算長期維護。

記錄下開發的一些事，加強自己對nodejs的應用。共勉！

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

操蛋的是，程序員是懶的，一般不會手動去刪除某個項目，導致于克隆的項目會越來越多。

對于這些項目的管理，則會變得越來越困難，放眼放去，全是文件夾。

所以，需求就誕生了。

參考于GO的項目管理，發現非常的優雅。

GO的項目類似的結構是這樣的

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

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

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

這樣基本就確定了一個項目目錄的唯一性。

簡單無腦，我只管克隆，卻不用管克隆的項目在哪個文件夾，想刪就刪。

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

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

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

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

支持克隆Github, Gitlab等等

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

支持插件，配置文件，hook

> 舉個簡單的例子，克隆一個Javascript項目，克隆之后，自動運行 npm install 或 yarn
> 想要什么樣的插件，什么用的hook，隨你配置

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

這樣會導致一些命令因為沒有權限而失敗

交互方式的選擇一直是我蛋疼的問題，又要兼容多平臺，又要簡單優雅。

比如 gpm find，搜索某個倉庫，然后獲取相應的信息

方式一：輸入(半)全稱

gpm find @gpmer/gpm.js

優點：

幾乎能精準搜索

跨終端兼容性好

缺點：

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

方式二：詢問/篩選

gpm find

會在終端監聽輸入的關鍵字，根據關鍵字篩選出一系列的倉庫。
然后通過上下箭頭，選擇倉庫

優點：

沒必要輸入繁瑣的關鍵字，只需要記得大概

缺點：

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

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

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

折中方案是加個-u, --unix參數, 選擇輸出unix的路徑

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

后來終于發現了robotjs自動化工具.

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

可惜的是, 又是Windows不兼容. 而且robotjs的包還不小, 對于頻繁升級是一種負擔.

所幸就放棄了自動cd到工作目錄的念頭

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

你可以在你的項目創建一個.gpmrc配置文件，里面寫一些hook，比如：

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

當通過gpm添加這個項目之后，則運行hooks里面對應的shell。

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

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

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

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

但是spawn("npm", "isntall && npm run build".split(" "))這樣是會報錯的. && 不是有效的命令

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

你可能已經在~/project/這個目錄下存放了很多的項目。如果要讓你重新gpm add xxxx一個一個的添加進來，你愿意嗎？

程序員要偷懶，所以才有import這個命令。把已存在的項目，按照source > owner > name的目錄結構擺放好。

這又涉及到一個問題。我又想導入，又不想破壞原來~/project/的結構，這個時候就用到link。

在對應的source > owner > name目錄下，創建一個link，指向~/project/中的項目

問題就來了，當你要刪除這個項目的時候，即刪除source > owner > name,會報錯。link文件需要解除link才能刪除

有找過類似mock文件系統的方案，但是都感覺不太優雅。

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

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

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

最后給上項目地址：gpmer/gpm.js

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