Пути к файлам Windows на узле npm слишком длинные для установки пакетов

Ситуация

Я хочу использовать gulp и связанные цепочки интерфейсных инструментов в средах разработки, размещенных в Windows. Я упираюсь в стену, пытаясь использовать подключаемые модули gulp, такие как Browser-Sync, потому что граф папок node_modules раздувается, делая пути к файлам Windows слишком длинными для копирования файлов. Я хотел бы прагматичный подход к решению этой проблемы прямо сейчас в Windows, независимо от того, что сообщество Node может или не может предоставить для улучшения удобства использования npm в Windows в будущем.

2 вопроса

1. Есть ли рабочий процесс npm для Windows, который работает именно так, как задумано? "запустить команду и установить файлы" (например, сравнимо с npm в OSX, npm в Linux, ruby ​​gems или даже nuget) Я не хочу возиться с кучей ручного редактирования файлов, символических ссылок и т. д. каждый раз, когда я использую npm в Windows.

2. Существует ли хорошо документированный и стабильный рабочий процесс Cygwin для выполнения npm и узлов, позволяющий обойти ограничения пути к файлам Windows API?

Кровавые подробности перечислены ниже ...

Общая проблема

• Выполнение установки npm из стандартной командной строки Windows завершается ошибкой в ​​глубоко вложенных иерархиях node_modules.
• Согласно потоку репозитория Joyent на github, это общепризнанная проблема, не имеющая приемлемых решений для разработчиков в средах, ориентированных на Windows. ( Правда? )
• Ядро NT поддерживает длину пути к файлу до 32 767 символов.
• MAXPATH Windows API ограничен 260 символами.
• Windows API обрабатывает файловые операции для всех основных оболочек Windows и еще много чего, включая: Explorer, CMD, Powershell, MYSgit bash и т. Д. ( MS, правда? Как давно NTFS существует? )
• Cygwin поддерживает длинные пути к файлам, но npm.cmd не работает "из коробки" из-за форматирования crlf. Я попробовал преобразование DOS2Unix в npm, чтобы заставить его работать с Cygwin, но, похоже, с этим есть другие проблемы.

Мой текущий взлом

• Создайте папку «n» в качестве промежуточной области в корне C: \, потому что это сокращает путь к моей папке.
• Запустите npm в папке "n", чтобы установить все необходимые модули.
• Запустите Cygwin и используйте cp, чтобы скопировать папку node_modules в целевой проект.
• Промыть и повторить, когда зависимости изменяются или когда мне нужно запустить новый проект.

Другие неприятные обходные пути

Символические ссылки можно использовать для сокращения путей к файлам, но это бесполезные уловки. По мере роста экосистемы npm вложенные цепочки зависимостей станут слишком длинными, и этот обходной путь станет непригодным для использования.

Добавление ВСЕХ зависимостей в файл package.json корневой папки упоминалось в одном потоке, с которым я столкнулся. Хотя такой подход сгладит структуру папок и предотвратит загрузку дублирующих модулей, этот обходной путь кажется неестественным. Это также убивает удобство использования, надежность и производительность npm, потому что вам придется возиться с файлами и папками после установки либо вручную, либо с помощью некоторых хакерских скриптов. Этот подход также подвержен той же участи, что и подход символических ссылок.

Проблема с глубоко вложенными папками в Windows в основном решена, начиная с версии npm 3.x.

Согласно npm:

.npm @ 3 делает установку «максимально простой», поднимая все, что возможно, на верхний уровень node_modules. Это означает, что вложение происходит только при конфликтах, и поэтому деревья никогда не должны заходить очень глубоко. Таким образом, ограничение длины пути окна не должно нарушаться.

Я только что установил npm 3.1.0и опробовал его на пакете, который выдавал ужасную The specified path, file name, or both are too longошибку.

Проблема ушла.

Вы можете получить последние сборки npm отсюда: выпуски npm

В Windows 8.1 и 10 есть возможность увеличить ограничение пути Win32:

• Откройте редактор групповой политики (нажмите Windows+, Rвведите gpedit.mscи нажмите Enter)
• Перейдите в следующий каталог: Local Computer Policy\Computer Configuration\Administrative Templates\System\Filesystem
• Дважды щелкните параметр Включить длинные пути Win32 и включите его.

Это обходное решение.

Есть несколько узловых модулей, которые сглаживают ваши зависимости за вас.
Ссылки здесь:

• npm-flatten
• npm-дедупликация

То, что делают эти модули, можно сделать и вручную. Это единственное реальное решение, существующее на данный момент, т.е. иметь все ваши модули на одном уровне, требующие друг друга, вместо того, чтобы все частные копии их зависимостей были глубоко вложены.

Аллан -

Из проблемы github, которую вы связали,

npm по умолчанию добавит дедупликацию во время установки. Это значительно более осуществимо, чем изменение модульной системы Node, но это все еще не совсем тривиально и включает в себя значительную переработку некоторых давно укоренившихся шаблонов.

Это (наконец) в настоящее время разрабатывается в npm по названию multi-stage-installи нацелено на npm@3. npmРуководитель разработки Форрест Норвелл собирается провести некоторое время в Windows в новом году, поэтому, пожалуйста, создавайте проблемы, связанные с Windows, в системе npmотслеживания проблем < https://github.com/npm/npm/issues >

У меня такая же проблема. Выравнивание зависимостей не является полным решением, поскольку вы можете использовать модули, которые зависят от разных версий одного и того же зависимого модуля. Я обнаружил, что модуль gulp-run перестал работать после сглаживания (я подозреваю, что это связано с предположениями модуля о каталогах bin / .bin). Драт!

О проблеме много говорят, но решения не видно: https://github.com/joyent/node/issues/6960

https://github.com/npm/npm/issues/3697

Для меня работает обходной путь - вручную добавлять зависимости, которые моему проекту явно не нужны.

Если вы хотите определить, какие пакеты вызывают проблемы, я нашел PathLengthChecker весьма полезным. Просто извлеките EXE и запустите приложение с графическим интерфейсом или командной строкой. Другой способ, которым я обнаружил проблему, - это попытаться выполнить сборку в Visual Studio, но это не удается, не сообщая вам, какое имя каталога слишком длинное.

Вот пример моего обходного пути из командной строки:

mkdir c:\reallylongdirectorywillbreakinwindows
cd c:\reallylongdirectorywillbreakinwindows
npm init
npm install --save-dev grunt-bower-task
PathLengthChecker.exe RootDirectory="C:\reallylongdirectorywillbreakinwindows" MinLength=260

Я вернулся:

261: C: \ действительноlongdirectorywillbreakinwindows \ node_modules \ grunt-bower-task \ node_modules \ bower \ node_modules \ update-notifier \ node_modules \ latest-version \ node_modules \ package-json \ no de_modules \ URL-адрес реестра \ node_modules \ npmconf \ node_modules конфигурационная цепочка \ readme.markdown

[snip - их было 12]

Согласно команде npm ls :

└─┬ grunt-bower-task@0.4.0
  ├── async@0.1.22
  ├─┬ bower@1.3.12
  │ ├─┬ update-notifier@0.2.0
  │ │ ├─┬ latest-version@0.2.0
  │ │ │ └─┬ package-json@0.2.0
  │ │ │   └─┬ registry-url@0.1.1
  │ │ │     └─┬ npmconf@2.1.1
  │ │ │       ├─┬ once@1.3.1
  │ │ │       │ └── wrappy@1.0.1

Давайте перейдем к npmconf - это контейнер для всех слишком длинных файлов, которые вызывают проблемы. Нам нужен npmconf 2.1.1.

npm install --save-dev npmconf@2.1.1
(now delete the node_modules directory - you may have to use Windows Explorer if you can't do it with rmdir /s)
npm install
PathLengthChecker.exe RootDirectory="C:\reallylongdirectorywillbreakinwindows" MinLength=260

Нет результатов - все файлы в пределах допустимого!

Очевидное предостережение заключается в том, что он работает только один раз для каждого пакета - зависимости от разных версий одного и того же модуля не могут быть установлены на корневом уровне node_modules, поскольку node не учитывает версии в структуре каталогов.

Этот обходной путь не идеален, но он решает мои основные цели, связанные с работой узла в Windows, и, поскольку решение находится прямо в package.json, обходное решение работает для других разработчиков и создает серверы без каких-либо ручных или глобальных проблем.

Если вы согласны с глобальной установкой, это может быть временным решением:

Вы можете настроить путь, по которому npm устанавливает глобальные модули, на что-то очень короткое (обычно это :), c:\users\\{username}\AppData\Roaming\npm\npm_modulesчто уже требует большого количества символов.

Чтобы настроить его, см. Здесь: Изменить глобальный установочный каталог по умолчанию для модулей node.js в Windows?

Если вы настроите его, например, c:\n\в некоторых случаях, это может решить проблему.

Это то, что окончательно исправило для меня ...

После установки gulp и получения ошибок запустите ... gulp

Если вы видите, что пакет не работает, установите его вручную с помощью --no-bin-link.

sudo npm install {package} --no-bin-link

Где {package} - это пакет, в котором возникли проблемы.

После всего этого я получал сообщение об ошибке в плагине gulp-notify: not found: notify-send.

Это произошло из-за проблемы с плагином Vagrant. Вы можете отключить уведомления ..

export DISABLE_NOTIFIER=true;

Или установите плагин с помощью Vagrant .

Желаю удачи ... Я потратил на это много времени, даже после того, как последовал рекомендациям многих людей.

Брэндон

В окнах:

1. Используя проводник Windows, перейдите в свою общую папку бродяги (кстати, я использую scotchbox), например C:\scotchbox/public/gulpProject
2. В адресной строке папки введите cmdи нажмитеEnter
3. Сделайте установку gulp npm install

npm install --no-bin-link. У вас будет весь сплющенный node_modules