Управление зависимостями: возможности и не возможности

Столкнулся с особенностями bower’a, как отсутствие аналога shrinkwrap и стратегия резолва версий, которая создает конфликты на ровном месте.

И возникла мысль: вот, есть куча менеджеров зависимостей со своими особенностями и ограничениями. А чего лично вам не хватало в том, что вы используете? Было ли нечто такое в менеджере А, что было в менеджере В реализовано однозначно лучше?

Хочу собрать мнения в надежде выкопать информацию, известную не всем.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

брейкинг чежес в минорных апдейтах — кстати решаемо — обязать выпускать тесты вместе с либой, и при минор апдейтах прогонять через тесты, иначе блочить

не совсем понял. разверни мысль, плиз.
это с точки зрения разработчика либы или с точки зрения пользователя либы?

с точки зрения пользователя либы. миллион раз было такое что минорный апдейт какойто либы содержал брейкинг ченджс — что рушило проект :(

о, да, такая ж фигня.
из свеженького: ануляровский ui-select при обновлении 0.19.6->0.19.7 схлопнулся и стал показывать маркеры во внутреннем ul/li.

но я тогда не пониманию, что значит «обязать» и «блочить»?
типа, я, как мейнейнер, в реестре обновлю только если тесты будут?
но мне ж тогда придется строить собственный ci, чтоб убедиться, что тесты не просто формальные, покрытие считать там.
и в итоге всё равно получится, что я не могу отловить breaking change(ибо прохождение тестов не гарантирует неизменности логики работы), а только удивленно спросить разработчика либы «так, ты ж тесты писал, не?»

да-да, как оно там, нет проблем при применении maven’a?

На офф. сайте bower’a есть такая обьява (сообщение):


...psst! While Bower is maintained, we recommend yarn and webpack for new front-end projects!
типа для новых проектов рекомендуют юзать ярн и вебпак.
Т.е. возможно для решения проблемы
отсутствие аналога shrinkwrap и стратегия резолва версий, которая создает конфликты на ровном месте.
стоит воспользоваться yarn’ом или webpack’ом? возможно оно есть там.

а так мне для своих нужд пока bower’а хватает, хотя yarn себе тоже поставил.

я всерьез рассчитывал, что люди начнут вываливать свою боль, а я бы потом это в какую-то статью агрегировал. бо попытался искать формальные сравнения, как на wiki, с табличкой фич и yes/no, и че-то не нашел.
Плюс, в принципе, удивлен, что разные package managers, похоже, изобретают свои собственные велосипеды на ровном месте :-/ потому и проблемы уникальные более-менее

В ember-cli используются bower и npm, хотя давно уже читал что от bower хотят отказаться. С особенностями не сталкивался. Сам в последнее время стараюсь избегать bower, так как считаю что удобнее когда всеми зависимостями управляет один менеджер.

то есть, чисто npm? а кто потом чистит дубликаты перед добавлением в бандл? вебпак такое умеет?

Какие дубликаты? node_modules в репозитории я не храню, поэтому дубликаты там меня не очень волнуют, а всякие библиотеки и жквери плагины подключаются явно — в конфиге прописывается какие файлы использовать.

Например:

/*jshint node:true*/
/* global require, module */
var EmberApp = require('ember-cli/lib/broccoli/ember-app');

module.exports = function (defaults) {
    var app = new EmberApp(defaults, {
        nodeAssets: {
            'semantic-ui-css': {
                import: ['semantic.js', 'semantic.css'],
                public: {
                    include: ['themes/**']
                }
            },
            'jquery.scrollto': {
                import: ['jquery.scrollTo.js']
            },
            'rangeslider-pure': {
                import: ['dist/rangeSlider.js', 'dist/rangeSlider.css']
            },
            'jquery.scrollbar': {
                import: ['jquery.scrollbar.js', 'jquery.scrollbar.css']
            }
        }
    });

    return app.toTree();
};

Ember-cli (который использует broccoli) потом собирает это всё в vendor.js и vendor.css. Дубликатов в этом случае быть не должно.

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

я про дубликаты, когда депенденси А хочет депенденси В только версии 1.5, а депенденси С хочет ту же депенденси В, но не ниже второй версии.
плоская структура, как у bower, считает это конфликтом, и требует выбрать вручную, что будет использоваться.
а npm говорит «та чё, мне пофиг, у меня это отдельные ветки файловой системы». Но ведь для браузера придется это всё собрать в один бандл, не?

Собрать придется, да. Но собирает ведь не npm и не bower.

Если собирает ember-cli, то зависимости я должен прописать в ember-cli-build.js чтобы они попали в бандл для браузера. И решать что добавлять нужно будет там. Ну кроме jquery, от которого зависит ember, который прописан в bower.json. Если нужно использовать jquery плагин, который требует какую-то особую версию, нужно будет добавить в bower.json, возможно решить конфликт, но jquery будет только один. Использовать две разные версии проблематично, лучше выбрать плагин поновее или написать самому.

Если это gulp, то аналогично — в gulpfile всё что нужно собрать в бандл прописывается. npm я использую только для того чтобы стянуть зависимости с гитхаба и не держать их в своем репозитории. А об утилите, которая соберет всё сама без конфига я как-то и не слышал.

Может я не совсем понял проблему?

А это частый кейс? звучит как костыль, да и сбандленный жс-ник походу разжиреет так быстро...

it depends.
чем больше зависимостей — тем выше вероятность, что «совсем такое, как тебе надо» последний раз полгода назад обновлялось. и выбор «свой велосипед с нуля» или «риск возможных проблем, которые при тестировании все равно выплыть должны» склоняется в сторону второго.

да и сбандленный жс-ник походу разжиреет
не-не, я гипотетически.
любой нормальный менеджер зависимостей не допустит такого, ведь там не только в дублировании дела, но и, например. глобальные переменные или обработчики событий.
Но ведь для браузера придется это всё собрать в один бандл, не?
ну по-моему для этого и существуют таск-раннеры и сборщики типа Gulp, Grunt и Webpack (и еще несколько менее известных типа brunch и broccoli). И у каждого свои особенности насколько знаю.

90% случаев с такими дубликатами лечится алиасами в вебпаке, насколько я помню.

npm не умеет складывать все зависимости в одну папку, как bower. что не то, чтоб плохо само по себе, но для фронтенд зависимостей явно так себе: в NPM blog прямо признают, что иметь потенциальную возможность получить две версии одной зависимости в параллель, которые могут что-то писать в глобальную область видимости или ставить обработчики событий на своё усмотрение — так себе идея. и предлагают писать собственные скрипты, которые будут скидывать зависимости в плоскую структуру. Как быть при этом с решением конфликта версий депенденси — не понятно.

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

или всё не так плохо?

В yarn есть „Flat mode”:

yarn install —flat
Only allow one version of a package. On the first run this will prompt you to choose a single version for each package that is depended on at multiple version ranges. These will be added to your package.json under a resolutions field.
yarnpkg.com/…​lang/en/docs/cli/install

мне интересно, что автор топика думает об этом комментарии про yarn с его flat mode. По описанию довольно круто звучит, вроде то что нужно

вообще, автор топика хотел простимулировать беседу в ключе «как страшно жить», собрать хотелки и различия, добавить своих :)
обмен мнениями и опытом.

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

Вроде бы в большинстве случаев должно так сработать (используя тот же package.json и пакеты из npm)

bower не умеет фиксировать принудительно все-все-все зависимости(и не прямые тоже) на определенную версию(текущую). И в ближайшее время уметь не будет. Рассчитывают на появление ментора, кто доведет вопрос до конца. npm, к примеру, имеет отдельную команду — shrinkwrap. А PHPшный composer автоматически создаст composer.lock сразу после установки зависимостей.

yarn (который фактически работает поверх npm) делает yarn.lock который мы кладем в репозиторий и у любого разработчика из команды пакет соберется одинаково. И как по мне, то я пока не вижу светлого будущего Bower в целом (есть же хорошие идеи, наверное) ... в конечном итоге разные экосистемы приходят к чему-то похожему что было уже в Bundler для рубистов (сейчас cargo для Rust, Yarn для JS ... Go тоже dep уже делает с похожими принципами хотя уже есть сторонние решения в том духе) ... просто JS немного хаотично развивался в этой области исторически ... а насчет дубликатов то тут более глубокая проблема, стараются в направлении tree shaking, но это еще не везде и не всегда работает ... да и возможно ли это решить однозначно — вопрос

Подписаться на комментарии