Comments 34
При добавлении пакета он (и все его зависимости), в виде zip архива добавляется в кеш, в папку .yarn в папке пакета (как .git)
И последствия
Можно добавлять этот кеш напрямую в гит — и тогда после чекаута у вас сразу будет актуальная версия приложения со всеми зависимостями.
Это кэш уровня проекта или пакета? Если пакета, то я получаю две копии одного и того же, одна установлена и в той же директории ещё и zip? В любом случае обычно не очень оптимально хранить иметь что-то, что можно потом установить с помощью пакетного менеджера. Это приведёт к тому, что репозиторий будет просто пухнуть, а при обновлерии пакетов в PR будут огромное количество файлов, которое по сути там не нужно.
Будет ли команда очистки кэша? Ну чтобы хоть каким-то образом поддерживать этот кэш в актуальном состоянии.
получаю две копии одного и того же, одна установлена и в той же директории ещё и zip
Только zip файл и будет. Далее в рантайме он маунтится как рид-онли раздел и нода читает из него, то есть он никуда не распаковывается и не устанавливается — добавление этого zip-архива и есть установка пакета.
https://next.yarnpkg.com/features/zero-installs#is-it-different-from-just-checking-in-the-node_modules-folder
Такая схема необязательна — потому локфайл и нужен. Плюсы у неё перед коммитом node_modules — гораздо меньше файлов, так что ФС и гит не подыхают. yarn в такой схеме становится чисто development-инструментом, то есть его даже не обязательно устанавливать на серверах (или там в CI-контейнере).
Тут есть один нюанс © — в опенсорс проектах злоумышленник может залить в zip-файл вредоносный код, чтобы этого избежать нужно запускать yarn в режиме проверки хеш-сумм — тогда он всё равно будет скачивать все файлы и сверять их.
Но вообще идеология этих переделок мне мягко говоря непонятна: в некотором окружении наличие npm от отсутствия npm заключается только в том, что во-первых вам придётся самому файлики положить на их нужные места, создав node_modules самостоятельно, а во-вторых — команды npm придётся запустить руками (второе совсем несложно). В итоге иметь какое-то окружение без npm (например, чтоб что-то гонять в браузере без посторонних средств) не слишком сложно, всё решается всего лишь размещением файлов в нужных местах.
А вот что мне делать без yarn2 с этими его PnP-файлами? Самому парсить и делать с ними то же, что делает yarn2? Спасибо.
Отсутствие yarn ничем от отсутствия npm не отличается: в обоих случаях у вас есть лишь package.json и ничего кроме него.
С npm, при наличии заранее сохранённых пакетов — вопрос только в том, чтоб эти пакеты положить в нужное место
Нужное место — это какое? Если вы про node_modules — то вне ноды это работать не будет, браузеры не ищут модули там.
Не вижу какие новые проблемы создает yarn.
Нужное место — это какое? Если вы про node_modules — то вне ноды это работать не будет, браузеры не ищут модули там.
Браузеры не ищут модули вообще нигде. Но если наперед известно место, где они окажутся, то остальное можно решить уже сейчас через import maps.
Не вижу какие новые проблемы создает yarn.
Неустранимая зависимость от ноды, очевидно.
Но если наперед известно место, где они окажутся, то остальное можно решить уже сейчас через import maps.
И что в этой схеме меняется от замены npm на yarn?
И что в этой схеме меняется от замены npm на yarn?
В том, что я почитал про эту схему — нигде не говорится, что пакеты будут выложены менеджером в какую-то предсказуемую структуру. Только про то, что вся линковка будет идти через .pnp.js.
Судя по вот этой цитате:
По поводу платформы же — парни перешли на архитектуру плагинов (то есть yarn в первую очередь как API, а уже потом как CLI)
вам и не нужна никакая предсказуемая структура. Вы можете во время сборки спросить о том где что лежит у самого yarn, и записать результат в ваши import maps.
PS
Вот цитата из документации, которая наконец-то открылась:
Plugins can add new linkers. Once all the packages have been located and are ready for installation, Yarn will call the linkers to generate the files needed for the install targets to work properly. As an example, the PnP linker would generate the .pnp.js manifest, and a Python linker would instead generate the virtualenv files needed.
Вот цитата из документации, которая наконец-то открылась:
Это уже гораздо интереснее, спасибо.
Для веба могу обратить внимание на pika.dev, позиционируют себя как условно браузерный npm (cdn с пакетами из npm), ES Modules-first. У них есть ещё утилита, которая под веб собирает и бандлит по пакетам все зависимости в отдельную папку.
А что не так с unpkg.org?
С unpkg.org всё вполне в порядке, хотя и не всегда ES Modules работают как надо. Я просто вкинул довольно новый проект, у которого слегка иной подход. И если я не ошибаюсь как раз у pika.dev есть поддержка import maps и их генерация. pika.dev пытаются стать именно универсальным регистром пакетов, который будет работать как в браузерах так и на серверах в Deno.
Не совсем. Просто пакеты зависимостей будут упакованы в zip-архивы, что в принципе не особо помешает их прочитать.
Нормальные библиотеки лежат в npm без исходников, в собранном и минифицированном виде.
Ну уж нет. Мой бандлер справится с минификацией сам как-нибудь. Оставьте мне в библиотеках не минификацированный код, чтобы я мог нормально дебажится при необходимости.
Так и не понял, какую проблему они пытаются решить, кроме "нам нечего делать".
"Давайте тащить в репу вместе с проектом все зависимости к нему" — ну офигеть теперь. Они там что, golang'ом вдохновлялись?
В общем, нет, спасибо. Подожду пару лет, пока всё устаканится, но сейчас я в эту идею не верю.
Популярность JavaScript сейчас напоминает популярность PHP когда-то. В PHP в своё время тоже постоянно менялись тренды, и пишущих на PHP не считали за программистов. А сейчас в экосистеме PHP тишь и благодать.
Yarn 2 — с Prolog'ом и плагнплеями