я использую Композитор чтобы управлять своими PHP-зависимостями, и был бы рад сделать то же самое с моими JS-зависимостями.
Я наткнулся на NPM для Node.js, и мне интересно, предполагается ли его использовать в качестве диспетчера зависимостей на стороне клиента.
Например, я мог бы захотеть управлять зависимостями клиентской библиотеки в моем приложении /public/vendor/ папку и установите / обновите эти зависимости, как я бы сделал с composer install или composer update для PHP.
Является npm для меня?
Есть восторженный случай, сделанный здесь, который заканчивается резюме:
Все менеджеры пакетов делают примерно одно и то же. Переместить файлы. Выберите менеджер пакетов, исходя из того, насколько хорошо он это делает. Все инструменты сборки делают примерно одно и то же. Преобразуйте файлы. Выбирайте инструменты сборки в зависимости от того, насколько хорошо они это делают. Если вы сейчас не используете npm только потому, что кто-то сказал вам, что это не для стороны клиента. Похлопайте их и скажите: «npm all the things».
Мой собственный взгляд на это: клиент и узел очень часто могут использовать общий код. Следовательно один день Для проектов клиентов и узлов будет разумным занимать один и тот же репозиторий. Какой бы репозиторий ни был, он (в идеале) наберет критическую массу и заменит все остальные клиентские репозитории и репозитории узлов. И поскольку npm уже так хорошо зарекомендовал себя, почему бы ему не стать этим репозиторием?
Не напрямую, хотя некоторые из пакетов, которые вы устанавливаете через npm (например, socket.io), будут генерировать клиентские библиотеки Javascript.
Есть еще один инструмент под названием Беседка который разработан для клиентских библиотек. Могут быть и другие, но об этом я упоминал больше всего. Он используется внутри Google Йомен инструмент для клиентских библиотек.
NPM был разработан специально для управления пакетами JavaScript, работающими под Node.js (на стороне сервера). Теперь, когда в каталоге ~ 80000 пакетов публичный репозиторий npm возникли некоторые проблемы с исходным дизайном (например, проблема с плоским пространством имен) и появились альтернативные менеджеры пакетов JavaScript.
Один, который до недавнего времени был нацелен на решение всех этих проблем с зависимостями пакетов на стороне сервера / стороны клиента / стороны JavaScript, - это component менеджер пакетов с использованием репозитория GitHub и его пространства имен.
Эта статья была в начале: http://tjholowaychuk.tumblr.com/post/27984551477/components
В настоящее время в каталоге ~ 2500 пакетов. публичный репозиторий компонентов.
Краткое сравнение с другими менеджерами пакетов JavaScript доступно здесь: https://github.com/component/guide/blob/master/component/vs.md
Об этом есть недавняя запись в блоге от NPM: http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging
«Npm предназначен только для серверного JavaScript!»
Тоже неправда. Ваш пакет может содержать что угодно, будь то ES6, клиентский JS или даже HTML и CSS. Это вещи, которые естественным образом появляются вместе с JavaScript, так что поместите их туда.
...
Если это связано с JavaScript, разместите его в npm. Как только они станут доступны, используйте экосистемы для создания «мини-реестров» в глобальном реестре, в комплекте с пользовательским индексированием поиска и характеристиками отображения.
Так да. Вполне нормально помещать клиентский JavaScript в NPM, и они улучшат поддержку этого.