节点npm Windows文件路径太长,无法安装软件包 [英] Node npm windows file paths are too long to install packages

查看:129
本文介绍了节点npm Windows文件路径太长,无法安装软件包的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

情况

我想在Windows托管的开发环境中使用gulp和相关的前端工具链.我遇到了尝试使用浏览器同步之类的gulp插件的麻烦,因为node_modules文件夹图散发出来,使得Windows文件路径太长而无法复制文件.我想要一种务实的方法来立即在Windows上处理此问题,而不管Node社区将来可能会或可能不会提供什么以改善Windows上的npm可用性.

I want to use gulp and related front-end tool chains in Windows-hosted development environments. I'm hitting a wall trying to use gulp plug-ins like Browser-Sync, because the node_modules folder graph fans out making the windows file paths too long to copy the files. I'd like a pragmatic approach for handling this problem right now on Windows, irrespective of what the Node community may or may not provide to improve npm usability on the Windows in the future.

2个问题

  1. 是否有Windows的npm工作流程能够按预期的方式工作? 运行命令并安装文件"(例如,与OSX上的npm,Linux上的npm,ruby gem甚至nuget相当),我不想每次都使用大量手动文件编辑,符号链接等摆弄. Windows上为npm.

  1. Is there an npm workflow for Windows that just works the way it was intended? "run the command and the files install" (e.g. comparable to npm on OSX, npm on Linux, ruby gems or even nuget) I don't want to fiddle with a bunch of manual file edits, symlinks, etc. every time I use npm on Windows.

是否存在用于npm和节点执行的有据可查的,稳定的Cygwin工作流,以解决Windows API文件路径限制?

Is there a well-documented, stable Cygwin workflow for npm and node execution to workaround the Windows API file path limits?

以下列出的详细信息...

Gory details listed below...

一般问题

  • 在深度嵌套的node_modules层次结构上,从标准Windows命令提示符运行npm安装失败.
  • 每个Joyent的github存储库线程,这是一个公认的问题,对于以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一起使用,但是似乎还有其他问题.
  • Running npm install from a standard Windows command prompt fails on deeply nested node_modules hierarchies.
  • Per Joyent's github repo thread, this is an acknowledged issue with no palatable workarounds for developers in Windows-centric environments. (Really?)
  • NT Kernel supports file path lengths up to 32,767 characters.
  • Windows API's MAXPATH is limited to 260 characters.
  • Windows API handles file operations for all major Windows shells and whatnot including: Explorer, CMD, Powershell,MYSgit bash, etc. (MS really? How long has NTFS been around?)
  • Cygwin supports long file paths, but npm.cmd doesn't work out-of-box due to crlf formatting. I tried the DOS2Unix transform on npm to get it working with Cygwin, but there seem to be other issues with this.

我当前的黑客行为

  • 在C:\的根目录上创建一个"n"文件夹作为暂存区域,因为 这缩短了我的文件夹路径.
  • 在"n"文件夹中运行npm以安装我需要的模块.
  • 启动Cygwin,并使用cp将node_modules文件夹复制到目标项目中.
  • 在依赖项更改或需要启动新项目时冲洗并重复.
  • Create an "n" folder as a staging area on the root of C:\, because this shortens my folder path.
  • Run npm inside the "n" folder to install modules for whatever I need.
  • Fire up Cygwin and use cp to copy the node_modules folder into a destination project.
  • Rinse and repeat when dependencies change or when I need to spin up a new project.

其他不适口的解决方法

符号链接可用于缩短文件路径,但这是肮脏的骇客.随着npm生态系统的发展,嵌套的依赖链将变得太长,并且这种解决方法变得不可用.

Symbolic Links can be used to shorten file paths, but these are kludgy hacks. As the npm ecosystem grows, nested dependency chains will become too long and this workaround become unusable.

将所有依赖项添加到根文件夹的package.json 文件中.尽管此方法将使文件夹结构变平并防止加载重复的模块,但是这种解决方法让人感到不自然.它还会破坏npm的可用性,耐用性和生产率,因为您必须手动或手动使用一些骇人的脚本来摆弄安装后的文件和文件夹.该方法也容易受到符号链接方法最终可能遭受的命运的影响.

Adding ALL dependences to the root folder's package.json file was mentioned in one thread I came across. Although this approach will flatten the folder structure and prevent loading of duplicate modules, this workaround feels unnatural. It also kills the usability, durability, and productivity of npm, because you have to fiddle with files and folders post-install either manually or with some hacky scripts. The approach is also vulnerable to the same fate that Symbolic Links approach may eventually suffer.

推荐答案

从npm版本3.x开始,大多数解决了Windows上深度嵌套文件夹的问题.

The problem with deeply nested folders on Windows has been mostly solved starting with npm version 3.x.

根据npm:

.npm @ 3通过将所有可能的一切提升到顶层node_modules,从而使安装最大程度地平坦".这意味着嵌套仅在冲突时发生,因此,树永远不会变得很深.因此,不应碰到Windows路径长度限制.

.npm@3 makes the install "maximally flat" by hoisting everything it can to the top level node_modules. This means nesting only occurs on conflicts and as such, trees should never get very deep. As such, the windows path length limitation shouldn't be run into.

我刚刚安装了npm 3.1.0,并在抛出可怕的The specified path, file name, or both are too long错误的程序包上进行了尝试.

I have just installed npm 3.1.0 and tried it out on a package that was throwing the dreaded The specified path, file name, or both are too long error.

问题消失了.

您可以从此处获取最新的npm版本: npm版本

You can get the latest npm builds from here : npm releases

这篇关于节点npm Windows文件路径太长,无法安装软件包的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆