Комментарии 7
Как утверждают сами авторы[2] новой системы, основной причиной является возможность запуска js кода на различных платформах: в браузере, на сервере или телефоне — то есть сейчас вы можете написать свой код на js один раз и запустить его в любом месте, но с этим могут возникнуть некоторые проблемы.
Всё равно непонятно, как из этого вытекает необходимость своей системы пакетов. Всего того же самого можно добиться на базе существующей системы. Содержимое npm и bower может быть совершенно различным. Так что их можно использовать как транспорт, при этом не нужно всё это заново писать:
Добавление, обновление и удаление пакетов, используемых в проекте, из командной строки;
Вывод списка установленных пакетов;
Кеширование пакетов — нет необходимости каждый раз загружать одинаковые пакеты для различных проектов;
Поиск пакетов по удаленному хранилищу, также поиск может осуществляться по закешированным пакетам;
Версионирование согласно спецификации Semantic Versioning и управление версиями пакетов;
Я думаю лучший вариант для тех, кто хочет сейчас запилить себе пакетную систему, это использовать npm в качестве менеджера пакетов, и использовать его без registry, вместо него использовать GitHub, как это сделали в bower (впрочем, registry тоже можно).
При этом к таким пакетам нужно предъявить некоторые дополнительные требования (интерфейс), которые и будут делать их конкретным пакетом конкретной местячковой системы. Т.е., пакет будет одновременно пакетом npm и более конкретным пакетом (например пакетом метеора), потому что в нём будет какое-то специфичное содержимое. Пакетам можно добавить какой-нибудь специальный тег, например <имя вашей пакетной системы здесь>-package и так их можно будет выделить в отдельную группу пакетов npm.
По сути вариант предложенный вами в Meteor и реализовали. Вы можете подключить любые пакеты из npm в пакет для метеора, у указать как правильно будут использоваться все зависимости. Так же вам ничего не мешает на основе каких нибудь gitmodules перенести библиотеки различных авторов в ваш проект.
Вся фишка в том, что в пакете можно явно определить какие части библиотеки будут доступны только на сервере, какие на клиенте, а какие и там, и там. Вы делаете свой пакет, например, который работает с редис, с клиента доступ к редису можно обеспечить только вызовом удаленных процедур, но ведь конечный api может быть единым как для сервера так и для клиента, все эти вызовы можно скрыть от пользователя и ему не понадобится вникать в суть работы и придумывать протоколы передачи, он просто где ему вздумается вызывает SuperLib.makeCool() и получает ожидаемый результат, без необходимости что-то подключать и настраивать. Идея подобной изоморфности и послужила созданием нового пакетного менеджера, потому что в противном случае нужно было бы стандартизовать форматы пакетов для других систем, и соответственно проку для разработчиков не для этого фреймворка от таких пакетов было бы мало.
И плюсом ко всему они сделали удобный апи для создания пакета и плюшки для управления этими пакетами.
Вся фишка в том, что в пакете можно явно определить какие части библиотеки будут доступны только на сервере, какие на клиенте, а какие и там, и там. Вы делаете свой пакет, например, который работает с редис, с клиента доступ к редису можно обеспечить только вызовом удаленных процедур, но ведь конечный api может быть единым как для сервера так и для клиента, все эти вызовы можно скрыть от пользователя и ему не понадобится вникать в суть работы и придумывать протоколы передачи, он просто где ему вздумается вызывает SuperLib.makeCool() и получает ожидаемый результат, без необходимости что-то подключать и настраивать. Идея подобной изоморфности и послужила созданием нового пакетного менеджера, потому что в противном случае нужно было бы стандартизовать форматы пакетов для других систем, и соответственно проку для разработчиков не для этого фреймворка от таких пакетов было бы мало.
И плюсом ко всему они сделали удобный апи для создания пакета и плюшки для управления этими пакетами.
Задача сборки gfrtnjd под разные окружения из одних исходников элементарно решается сборщиком. Велосипедить для этого отдельный пакетный менеджер вовсе нужно.
Например, можно помечать файлы и директори специальными тэгами:
my/http/http.js — общий код для всех окружений
my/http/http.env=web.js — специфичный код для веб окружения
my/http/http.env=node.js — специфичный код для ноды
my/http/http.env=gecko.js — специфичный код для расширений мозиллы
А сборщик, понимая их, будет собирать отдельные пакеты для разных окружений.
Например, можно помечать файлы и директори специальными тэгами:
my/http/http.js — общий код для всех окружений
my/http/http.env=web.js — специфичный код для веб окружения
my/http/http.env=node.js — специфичный код для ноды
my/http/http.env=gecko.js — специфичный код для расширений мозиллы
А сборщик, понимая их, будет собирать отдельные пакеты для разных окружений.
А сборщик, понимая их, будет собирать отдельные пакеты для разных окружений.
Но в метеоре один пакет собирается, только в случае использования архитектурно зависимого кода будут собираться разные билды, но это, опять же, ни как не повлияет на процесс подключения пакетов в проект.
Задача сборки пакета под разные окружения из одних исходников элементарно решается сборщиком. Велосипедить для этого отдельный пакетный менеджер вовсе нужно.
Например, можно помечать файлы и директори специальными тэгами
На счет велосипеда не согласен. Чтобы подключить пакет в проект на метеоре, достаточно ввести одну строчку, после чего даже страничка сама обновится. Для сборки самого пакета они сделали апи, которое сильно облегчает процесс сборки, нет нужды как то именовать файлы или даже вообще придерживаться какой то структуры. Модульное тестирование из коробки. Собственное хранилище этих пакетов, что облегчает поиск и дает удобство при использовании их менеджера в проектах на метеоре. И это помимо поддержки особенностей разработки на метеоре в принципе. Как мне кажется они сделали это, не потому что npm имеет один фатальный недостаток, а просто так было проще, а пользователем от этого стало удобнее, все в плюсе.
Для подключения npm пакетов в метеор кстати есть решение, причем как и с npm нужно описать лишь один файл с зависимостями, этим решением многие пользуются.
А вот наоборот использовать пакеты из метеор в других проектах не получится, так зачем их хранить где-то на стороне?
На счет того что мало пакетов, так это пока, люди активно портируют библиотеки, и даже самому это можно сделать очень быстро в случае необходимости.
Конечно можно было создать какой то сборщик, с хитрыми правилами и прочими надстройками. Но думаю люди именно это и попытались сначала сделать, а потом появился метеорит, а потом его функциональность была перенесена в метеор.
Можете дополнительно ознакомится с официальным ответом на вопрос «зачем нужен этот пакетный менеджер?», возможно там найдете какие-то ответы.
Давайте без маркетинга, я не ваша целевая аудитория. Отсутствие соглашений по структуре приводит к куче конфигов, чем, впрочем, и npm страдает. Всё, что вы написали вполне реализуется на npm и даже без каких либо пакетных менеджеров. Я не имею ничего против велосипедов, но не надо лукавить будто он чем-то сильно лучше. А то, что модули метеора железными болтами прикручены к их стеку — не делает им чести.
Я и не говорю что он лучше, просто в контексте метеора это очень удачное решение, и от этого всем стало только лучше. На счет железных болтов, то да, могут возникнуть некоторые неудобства, но не такие что будут большой дискомфорт доставлять.
Еще немного маркетинга
Могу посоветовать ознакомится, мне за пару месяцев он сильно понравился, но опять же так совпало, что проект как будто под него был придуман. До этого было пару проектов на nodejs и socket.io, так я прям радуюсь как ребенок каждый раз когда вроде бы сложные вещи, на которые бы потребовалось потратить пару дней с тем стеком, на метеоре пишутся в три строчки. Если вы с ним знакомы, и вам не понравилось, ну увы.
я не ваша целевая аудитория
Могу посоветовать ознакомится, мне за пару месяцев он сильно понравился, но опять же так совпало, что проект как будто под него был придуман. До этого было пару проектов на nodejs и socket.io, так я прям радуюсь как ребенок каждый раз когда вроде бы сложные вещи, на которые бы потребовалось потратить пару дней с тем стеком, на метеоре пишутся в три строчки. Если вы с ним знакомы, и вам не понравилось, ну увы.
Я не считаю mongodb полноценной базой ввиду примитивной модели данных (на которой и построен метеор) и отсутствия acid.
Я использую windows и предпочитаю кроссплатформенные инструменты типа nodejs+npm, которые не требуют жонглирования виртуалками.
Я предпочитаю не смешивать вёрску и логику, потому что это неизбежно приводит к лапше. Для логики лучше подходят языки программирования. Для вёрски — хтмл.
Ну и как любой full-stack фреймворк, метеор сильно связывает руки позволяя легко и просто делать проекты «под него заточенные» и очень сложно «не заточенные».
Я использую windows и предпочитаю кроссплатформенные инструменты типа nodejs+npm, которые не требуют жонглирования виртуалками.
Я предпочитаю не смешивать вёрску и логику, потому что это неизбежно приводит к лапше. Для логики лучше подходят языки программирования. Для вёрски — хтмл.
Ну и как любой full-stack фреймворк, метеор сильно связывает руки позволяя легко и просто делать проекты «под него заточенные» и очень сложно «не заточенные».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Система пакетов в Meteor