记录一下我对gpm，Git仓库管理工具的开发过程

前言记录下开发的一些东西，加强我对nodejs的应用。共勉！如果有什么让你他妈的，那就是需求。对于经常参与开源贡献的人，或者看到某些库，喜欢动手的人，经常需要gitclonehttps://xxxx妈的，程序员都是懒惰的，一般不需要手动删除某个项目，导致越来越多的克隆项目。对于这些项目的管理，难度会越来越大。如果环顾四周，它们都是文件夹。于是，需求诞生了。原型基于GO的项目管理，发现非常优雅。GO项目类似的结构是这样的https://{source}/{owner}/{name}-source-owner-name-name-owner-name-name-name-source-owner-name-namesojust想写一个类似的功能。这基本上决定了一个项目目录的唯一性。简单粗暴，我就是clone，但是我不管克隆的工程在哪个文件夹，想删就删。于是，git-clone-cli的原型诞生了。这只是一个简单的工具开发，用来替代gitclonexxx。随着需求越来越大，已经不能满足简单的gitclone，于是gpm来了。相对于gitclone，它丰富了一些东西，更方便我们管理和支持克隆Github、Gitlab等各种命令，比如list、find、clean、relink、import支持插件，配置文件，hook>举个简单的例子，clone一个Javascript项目，clone后自动运行npminstall或者yarn>你要什么样的插件，用什么hooks，你踩过的那些坑你自己去配置。FIXME：在Windows下，如果克隆到一半，手动中断进程，克隆的项目是只读的，不能修改，也不能删除。尝试通过node修改权限为777，最后还是不行，什么都没有。这会导致某些命令失败，因为它们没有权限。交互方式的选择一直是我的痛处。一定要兼容多平台，一定要简洁大方。比如gpmfind，搜索某个仓库，然后得到相应的信息方法一：输入gpmfind的（半）全名@gpmer/gpm.js优点：几乎准确搜索跨终端兼容性好缺点：太繁琐，除了自己的库，别人的库我都不记得了。方法二：Query/Screengpmfind会监听终端中输入的关键词，根据关键词筛选出一系列仓库。然后使用向上和向下箭头选择仓库。优点：不用输入繁琐的关键字，记住大致的缺点：有兼容性问题，linux和OSX下没问题，Windows下兼容pwoerShell和cmd，但不兼容gitbashunix路径和Windows路径Linux和OSX都是unix风格的路径。在gpmaddxxx中直接复制路径cd到对应目录即可。在Windows下，如果您使用GitBash，您将获得一个Windows风格的路径。很明显，cd是不可能的。折衷方案是加一个-u,--unix参数，选择输出unix路径添加仓库，在nodejs中自动cd到终端中的项目目录。不管你怎么改变工作目录，都只是改变了这个（子）进程的工作目录。无法更改所用终端的工作目录。后来终于发现了robotjs这个自动化工具。可以在终端输入命令，然后回车。不幸的是，Windows不兼容。而且robotjs的包也不小，频繁升级是个负担。还好我放弃了自动cd到工作目录的想法。全局插件FIXME：新增插件机制，丰富部分功能。克隆后，自动运行npminstall或yarn。只需要在命令后面加一个参数：gpmaddxxx-p引用全局插件，你必须知道npm的全局node_modules在哪里。不幸的是，在Windows下，获取到的位置不正确，导致插件无法正常调用。项目的.gpmrc配置文件你可以在你的项目中创建一个.gpmrc配置文件，在里面写一些hooks，比如：{"hooks":{"add":"npminstall"}}添加这个项目后通过gpm，然后在hooks中运行相应的shell。FIXME问题出在这个shell上，它不安全。如果rm-rf/恰好以root权限运行，那就悲剧了。还有多个shell，比如如何运行npminstall&&npmrunbuild。这不是很容易吗？只需exec("npmisntall&&npmrunbuild")就可以了，不，不，不。exec()不优雅且有局限性，我更喜欢spawn但spawn("npm","isntall&&npmrunbuild".split(""))会报错。&&不是有效命令。事实上，我就是这么做的。上面的命令分为两个spawn("npm",["isntall"])和spawn("npm",["run","build"])来导入现有的项目你可能已经有很多项目存储在~/项目/目录。要不要让你一个个加gpmaddxxxx？程序员要偷懒，所以才有了import命令。按照source>owner>name的目录结构排列已有的项目。这就带来了另一个问题。想重新导入，但是又不想破坏原来的~/project/结构，所以这时候就用link了。在对应的source>owner>name目录下，在~/project/中创建一个指向该项目的链接。问题来了。当要删除这个项目时，deletesource>owner>name，会报错。需要取消链接文件才能删除测试用例。我找到了类似mock文件系统的解决方案，但都感觉不够优雅。有一天，突然明白为什么还有模拟的文件系统，为什么不能用真实的，临时建立一个目录，在这个目录下完全走一遍流程，然后对比一下预期，是不是很好？我开始写作。到现在已经有300多个commit了，我一个人用了一个多月了。个人觉得比较好用（聊胜于无，逃避。。。）总觉得还有很多问题有完善的地方，但个人能力和想法有限，只能慢慢完善。我自己在用，打算长期维护。最后给出项目地址：gpmer/gpm.js我只是个菜鸟XD，希望有人PR或者给点建议