Как стать автором
Обновить

Комментарии 34

НЛО прилетело и опубликовало эту надпись здесь
Когда-то давно мигрировал на pnpm, надоело изобилие мелких файлов, повторяющихся от проекта к проекту, во всех папках node_modules.
При добавлении пакета он (и все его зависимости), в виде zip архива добавляется в кеш, в папку .yarn в папке пакета (как .git)

И последствия
Можно добавлять этот кеш напрямую в гит — и тогда после чекаута у вас сразу будет актуальная версия приложения со всеми зависимостями.


Это кэш уровня проекта или пакета? Если пакета, то я получаю две копии одного и того же, одна установлена и в той же директории ещё и zip? В любом случае обычно не очень оптимально хранить иметь что-то, что можно потом установить с помощью пакетного менеджера. Это приведёт к тому, что репозиторий будет просто пухнуть, а при обновлерии пакетов в PR будут огромное количество файлов, которое по сути там не нужно.

Будет ли команда очистки кэша? Ну чтобы хоть каким-то образом поддерживать этот кэш в актуальном состоянии.
получаю две копии одного и того же, одна установлена и в той же директории ещё и zip

Только zip файл и будет. Далее в рантайме он маунтится как рид-онли раздел и нода читает из него, то есть он никуда не распаковывается и не устанавливается — добавление этого zip-архива и есть установка пакета.

Т.е. получается я фактически кладу в репозиторий все свои зависимости и таскаю это за собой. В чем принципиальная разница с тем, чтобы я сейчас залил в репу node_modules? Т.е. разворачивание у меня сводится просто к чекауту и всё. Возникает вопрос, зачем мне тогда .lock файл, если все зависимости я таскаю с собой в репозитории? Да и вообще тогда получается мне yarn нужен только чтобы залить зависимости в репозиторий. Я верно понимаю?

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 в режиме проверки хеш-сумм — тогда он всё равно будет скачивать все файлы и сверять их.

думал, тут что-то о языке Prolog, но нет…
Вы не один такой :(

Пролог есть, он используется для декларативной проверки воркспейсов

Так, а о чём тогда?
Prolog жив… не ожидал
А победит как обычно тот, кто побыстрее станет совместим с браузерами: туда уже медленно, но вползают import maps.

Но вообще идеология этих переделок мне мягко говоря непонятна: в некотором окружении наличие npm от отсутствия npm заключается только в том, что во-первых вам придётся самому файлики положить на их нужные места, создав node_modules самостоятельно, а во-вторых — команды npm придётся запустить руками (второе совсем несложно). В итоге иметь какое-то окружение без npm (например, чтоб что-то гонять в браузере без посторонних средств) не слишком сложно, всё решается всего лишь размещением файлов в нужных местах.

А вот что мне делать без yarn2 с этими его PnP-файлами? Самому парсить и делать с ними то же, что делает yarn2? Спасибо.

Отсутствие yarn ничем от отсутствия npm не отличается: в обоих случаях у вас есть лишь package.json и ничего кроме него.

Именно так. И вопрос в том, сколько действий нужно проделать, чтоб обойтись без менеджера. С npm, при наличии заранее сохранённых пакетов — вопрос только в том, чтоб эти пакеты положить в нужное место. С yarn — теперь у нас есть какой-то код (.pnp.js), предназначенный для ноды, и неизвестно, будет или не будет этот код выполняться не в ноде.
С 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.

Правильно ли понимаю, что с отсутствием node_modules я потеряю возможность читать исходники зависимостей, установленных локально?

Не совсем. Просто пакеты зависимостей будут упакованы в zip-архивы, что в принципе не особо помешает их прочитать.

Нормальные библиотеки лежат в npm без исходников, в собранном и минифицированном виде.

Статистика моего node_modules говорит о том, что нормальных библиотек не существует. Ни одна из них не проходит условие «без исходников».

Ну уж нет. Мой бандлер справится с минификацией сам как-нибудь. Оставьте мне в библиотеках не минификацированный код, чтобы я мог нормально дебажится при необходимости.

Согласен. Иногда приходится дебагом поездить, а в крайних случаях дописать в пакете console.log или ещё что-то для экспериментов.

Так и не понял, какую проблему они пытаются решить, кроме "нам нечего делать".


"Давайте тащить в репу вместе с проектом все зависимости к нему" — ну офигеть теперь. Они там что, golang'ом вдохновлялись?


В общем, нет, спасибо. Подожду пару лет, пока всё устаканится, но сейчас я в эту идею не верю.

Так-то в golang уже некоторое время все в порядке. Это в мире JavaScript никак не устанут изобретать велосипед.

Популярность JavaScript сейчас напоминает популярность PHP когда-то. В PHP в своё время тоже постоянно менялись тренды, и пишущих на PHP не считали за программистов. А сейчас в экосистеме PHP тишь и благодать.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.