情况
我想在Windows托管的开发环境中使用gulp和相关的前端工具链。我碰到一堵墙,试图使用浏览器同步之类的gulp插件,因为node_modules文件夹图呈扇形散开,使得Windows文件路径太长而无法复制文件。我想采用一种务实的方法来立即在Windows上处理此问题,而不管Node社区将来可能会或可能不会提供什么以改善Windows上的npm可用性。
2个问题
是否有Windows的npm工作流程能够按预期的方式工作?“运行命令并安装文件”(例如,相当于OSX上的npm,Linux上的npm,ruby gem甚至是nuget)我不想每次都使用大量手动文件编辑,符号链接等摆弄在Windows上为npm。
是否存在针对npm和节点执行的有据可查的,稳定的Cygwin工作流程,以解决Windows API文件路径限制?
以下列出的血腥细节...
一般问题
- 从标准Windows命令提示符运行npm install在深度嵌套的node_modules层次结构上失败。
- Per Joyent的github repo线程,这是一个公认的问题,对于以Windows为中心的环境中的开发人员而言,没有可口的解决方法。(真的吗?)
- NT内核最多支持32,767个字符的文件路径长度。
- Windows API的MAXPATH限制为260个字符。
- Windows API处理所有主要Windows Shell的文件操作,但不包括:Explorer,CMD,Powershell,MYSgit bash等。(MS真的吗?NTFS已经存在多长时间了?)
- Cygwin支持长文件路径,但是由于crlf格式,npm.cmd不能开箱即用。我尝试在npm上进行DOS2Unix转换,以使其与Cygwin一起使用,但是似乎还有其他问题。
我目前的骇客
- 在C:\的根目录上创建一个“ n”文件夹作为暂存区域,因为这会缩短我的文件夹路径。
- 在“ n”文件夹中运行npm以安装我需要的模块。
- 启动Cygwin,并使用cp将node_modules文件夹复制到目标项目中。
- 当依赖项更改或需要启动新项目时,请冲洗并重复。
其他不适口的解决方法
符号链接可用于缩短文件路径,但这些都是笨拙的技巧。随着npm生态系统的发展,嵌套的依赖链将变得太长,并且这种解决方法变得不可用。
我遇到的一个线程提到将所有依赖项添加到根文件夹的package.json文件中。尽管此方法将使文件夹结构变平并防止加载重复的模块,但是这种解决方法让人感到不自然。它还会破坏npm的可用性,耐用性和生产率,因为您必须手动或手动使用一些骇客脚本来摆弄安装后的文件和文件夹。这种方法也容易受到符号链接方法最终可能遭受的命运的影响。