情况
我想在Windows主机的开发环境中使用gulp和相关的前端工具链。我试图使用像Browser-Sync这样的gulp插件时遇到了问题,因为node_modules文件夹图形展开,使得Windows文件路径太长而无法复制文件。我希望有一个务实的方法来解决这个问题,不考虑Node社区未来是否会提供改进npm在Windows上可用性的方案。
2个问题
是否有适用于Windows的npm工作流程只需"运行命令,文件安装完成"即可(例如与OSX上的npm、Linux上的npm、Ruby Gems甚至Nuget相当)?我不想每次在Windows上使用npm时都要动手编辑一堆文件、符号链接等。
是否有一个经过充分文档化并且稳定的Cygwin工作流程,可绕过Windows API文件路径限制进行npm和node执行操作?
以下是详细信息...
通用问题
- 从标准的Windows命令提示符中运行npm install,在深度嵌套的node_modules层次结构中失败。
- 根据Joyent的github存储库线程,这是一个公认的问题,没有可接受的解决方案供Windows环境下的开发人员使用。(真的吗?)
- NT内核支持长达32,767个字符的文件路径长度。
- Windows API的MAXPATH限制为260个字符。
- Windows API处理所有主要的Windows shell和诸如Explorer、CMD、Powershell、MYSgit bash等文件操作。(MS真的吗?NTFS已经存在多久了?)
- Cygwin支持长文件路径,但npm.cmd无法直接使用,因为换行符格式不正确。我尝试对npm进行DOS2Unix转换以使其与Cygwin配合使用,但好像还有其他问题。
我目前的技巧
- 在C:\根目录下创建一个名为“n”的文件夹作为暂存区,这可以缩短文件路径。
- 在“n”文件夹内运行npm以安装所需模块。
- 启动Cygwin并使用cp命令将node_modules文件夹复制到目标项目中。
- 当依赖项更改或需要启动新项目时,请重复上述步骤。
其他不可取的解决方案
符号链接可用于缩短文件路径,但这些是笨拙的解决方案。随着npm生态系统的增长,嵌套的依赖链会变得过长,使得这种解决方案变得难以使用。
将所有依赖项添加到根文件夹的package.json文件中在我看到的一个帖子中提到。虽然这种方法会扁平化文件结构并防止加载重复的模块,但这种解决方案感觉很不自然。它还会破坏npm的可用性、耐久性和生产力,因为您必须在安装后手动或使用一些笨拙的脚本来处理文件和文件夹。这种方法也容易受到符号链接方法可能最终遭受的同样命运的影响。