Для чего нужны пакетные менеджеры для js, например Yarn?
Сначала то, что понял, потом то, что неясно.
Node.js - это интерпретатор Javascript'а на серверной стороне.
Вообще Javascript - это клиентский язык программирования, исполняется на стороне клиента в браузере. Потом кто-то подумал, а почему бы его не использовать на стороне сервера, нафига доп. трудности, знаю яваскрипт, хочу использовать везде. Но на сервере нет браузера, поэтому придумали инструмент, который бы понимал и исполнял Javascript-код на сервере. Этим инструментом стал Node.js. Его устанавливали прямо на сервер и он делал свое дело. Нужно это было для того, чтобы писать серверные приложения на js, верно? При чем здесь вообще менеджер пакетов npm? Зачем он был нужен для node?
С bower все ясно. Надоело на фронтенде таскать всякие jquery-плагины, js-плагины, и пр. код, созданный разными людьми с сайтов и с гитхаба вручную. Захотелось удобства, создали инструмент. Тыкнул команду - в папку упал весь код, подключил его тегом script на странице с html и радуешься.
Теперь немного забегу вперед. NPM и bower до недавнего времени имели отличия. Сейчас их вроде бы и нет. Дальнейшим развитием npm является yarn, который имеет смысл использовать хотя бы из-за его скорости (параллельной установки). Работает с теми же библиотеками, что и npm.
Теперь вопросы:
1) При чем здесь NPM? На кой черт он сдался Node'у? И как он перекочевал во фронтенд? Это просто интересная фича Node, которую начали использовать фронтендеры, а bower развивался параллельно?
2) Получается, что для bower'a адаптированы одни библиотеки, другие не адаптированы. То же - для npm? Теоретически, могут не пересекаться?
3) Зачем мне (буду говорить просто) на "сайте" какой-то файл package.json, lock.json? И вообще, зачем мне какие-то зависимости? Установка - да, удобно. Но ведь все условно плагины (галерейки, jquery и пр., и пр.) являются частью сайта и друг от друга не зависят обычно. Максимум - плагин jquery зависит от самой jquery. Плюс к этому в преимущество записывается то, что вы можете передать файл lock.json и в точности воссоздать рабочую среду на другом компьютере. Зачем? У меня все хранится shared-папке Вагранта: все файлы проекта, все подключаемые библиотеки, БД - там же в файлах миграций (пользуюсь Laravel). Надо передать среду разработки - отдаю vagrantfile. Надо передать проект - копирую его папку и отдаю, человек разворачивает базу данных и все работает. Как бы выглядел тезис про преимущество?.. отдаю нужному человеку папку public без картинок без скриптов и без css, а он: "Так-так, круто, где здесь lock.json, сейчас я все яваскрипты закачаю в папочку". И давай грузить скрипты. Таким макаром можно и картинки в зависимость друг от друга ставить и грузить сторонним инструментом, css... В чем преимущество? Не понимаю. Если есть целевое использование, с которым я просто не столкнулся, то расскажите. Может, это необходимо только для одностраничных приложений на React, например, когда в нем используются вызовы, относящиеся к конкретному плагину (а они там и сложнее по структуре и уже завися друг от друга), и он должен быть?
4) Разработчики bower на своем сайте написали, что лучше использовать Yarn. Все, забываю про bower, забываю про npm? Я за прогресс без идеологических предпочтений. Лучше то, что удобнее и лучше.
5) Еще раз. Применительно к веб-разработке. Все три инструмента: Yarn, NPM, Bower - используются для одного и того же?
Упрощая, для составления списка необходимых js-библиотек для конкретного сайта (проекта) и автоматической и удобной их установки, но на этапе создания сайта, потому как дальнейшее применение такого списка сомнительно. Просто шли и развивались эти инструменты параллельно и своими путями. Теперь все пересеклись, и в лидерах останется что-то одно?
1) При чем здесь NPM? На кой черт он сдался Node'у? И как он перекочевал во фронтенд? Это просто интересная фича Node, которую начали использовать фронтендеры, а bower развивался параллельно?
Это пакетный менеджер, чтобы распространять пакеты централизованно, а не искать по всем закоулкам интернета. К этому пришли/придут все языки/среды разработки. У c# есть nuget, у php - composer...
3) Зачем мне (буду говорить просто) на "сайте" какой-то файл package.json, lock.json? И вообще, зачем мне какие-то зависимости? Установка - да, удобно. Но ведь все условно плагины (галерейки, jquery и пр., и пр.) являются частью сайта и друг от друга не зависят обычно.
все условно плагины
Это хорошо, если написанный Вами код использует только зависимости первого уровня вложенности. В проектах бОльшего масштаба, вложенность зависимостей может достигнуть и 3 и 5 уровней. Это когда используемый Вами пакет зависит еще от трех пакетов, каждый из которых, в свою очередь, зависит еще от нескольких, каждый из которых может принести еще несколько зависимостей... Соберете руками?
Максимум - плагин jquery зависит от самой jquery.
Это в Вашем кейсе так. Но не значит, что у всех поголовно.
Надо передать среду разработки - отдаю vagrantfile
vagrant - сторонняя зависимость.
Вы не смотрите, что Node.js - весь такой из себя сервер. Это в первую очередь тулчейн для разработки, а потом уже интерпретатор js. Ибо исторически, до появления node, сама только мысль о js на сервер-сайде вызывала эмоции вида "WTF? O_o Seriously?" и "LOL xD". Потому node.js релизился именно как готовый тулчейн для разработки поверх интерпретатора js. То, что над репозиторием npm появились другие менеджеры - это работа сообщества. Чем они лучше/хуже и в каких кейсах - думаю, практикующие люди вам ответят сегодня. Хотя, скорее всего отправят в поиск.
