[devel] Policy по упаковке модулей Node.js

[devel] Policy по упаковке модулей Node.js

[Vitaly Lipatov]

Хочу предложить на обсуждение полиси по упаковке модулей для Node.js:
https://www.altlinux.org/Node.js_Policy


-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Policy по упаковке модулей Node.js

[Anton Farygin]

On 28.02.2020 00:27, Vitaly Lipatov wrote:
> Хочу предложить на обсуждение полиси по упаковке модулей для Node.js:
> https://www.altlinux.org/Node.js_Polic

Спасибо. Выглядит хорошо, намного лучше чем без него.

Re: [devel] Policy по упаковке модулей Node.js

[Ivan A. Melnikov]

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

On Fri, Feb 28, 2020 at 06:46:52AM +0300, Anton Farygin wrote:
> On 28.02.2020 00:27, Vitaly Lipatov wrote:
> > Хочу предложить на обсуждение полиси по упаковке модулей для Node.js:
> > https://www.altlinux.org/Node.js_Policy
> 
> Спасибо. Выглядит хорошо, намного лучше чем без него.

+1

-- 
  wbr,
    iv m.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [devel] Policy по упаковке модулей Node.js

[Скрылевъ Малъ]

28.02.2020, 00:28, "Vitaly Lipatov" <lav@altlinux.ru>:
> Хочу предложить на обсуждение полиси по упаковке модулей для Node.js:
> https://www.altlinux.org/Node.js_Policy
>

>    Важно учитывать, что модулей для node (npm-пакетов) многие тысячи, и никакого смысла собирать в репозиторий в виде rpm-пакетов их нет, тем более невозможно учесть разницу в версиях.
>    Необходимо собирать в пакеты только те модули, которые требуют компиляции (с системными библиотеками), а также модули, которые являются программами в /usr/bin (например, npm, yarn, sass, node-gyp и подобное).``

Думаю тут не нужно впрадать в крайности, типа есть модулей тычячи то и собирать их не надо. Я считаю, что каждый модуль должен быть форомблен в качестве пакет, по двум причинам: 
* переиспользование модуля приложениями, и другими модулями, потому что кроме того, что есть несколько приложений, которые за собою тащат много повторяющихся модулей, но и модули этих приложений также тащат уже повторные копии тех же самых модулей, что приводит к тому,что в одном пакете приложения, я насчитаю несколько единиц копий одного и того же модуля, а для модулей нижнего уровня этот счёт по видимости может составлять десятки.
* разрешение путаницы как для наших так и для сторонних разработчиков, путаницы такой что будут обязательно вопрос почему это  такой-то модуль собран отдельно а такой-то нет. А где вопросы там и смущение....

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

> Программа на nodejs не является модулем для nodejs, поэтому указывать префикс, как у модуля, не требуется.
Что тут понимается под понятием программа?

Я тут бы разделил, на 2 понятие - приложение и утилита:
* приложение это любое приложение на node, зависимости запуска и работу которого определяются в том числе файлом описания проекта package.json, но при этом, оно не опубликовано на npmjs (не nodejs, такого понятия в мире node нету %) )
* утилита - собственно в некотором роде тоже программа, как правило оформленная в виде запускаемого файла, в котором в качестве интерпретатора указано node.

Ну и правила оформления такие: 
для приложения это srpm имеет имя без nodejs/npmjs, целевые rpm также
для утилиты srpm может иметь префикс nodejs/npmjs, если этот фай находится в репозитории npmjs, а целевые rpm делятся на библиотеку с темже префиктом, и утилиту - без префикса, ну по типу деления в обычных компилируемых модулях, напр: soft/libsoft, дада тут префикс имеет смысл именно как в этом паре. 

>Название пакета с модулем для node: nodejs-<имя>.

Я сторонник npmjs, как более понятного для внешнего разработчика знакомого с фреймворком node.

> И ассоциироваться такой префикс должен не с хранилищем (то есть с сайтом, который и поменяться может), а с названием экосистемы для пакетов, среды их исполнения. 

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

> Традиционно принято в качестве префикса использовать название языка. Так в репозитории Сизиф есть пакеты erlang-*, python-*, perl-*, ruby-*, php-* java-*. Возможно кому-то показалось, что это названия языков, на которых написаны модули. Нет, зачастую такие модули написаны на C, а не на php. И префикс имени пакета для языковых систем показывает, расширение какого языка поставляет этот пакет.

Я уже написал, что для ruby/python/erlang это недействительно 


--
> С уважением,
> Виталий Липатов,
> ALT Linux Team
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 

Малъ Скрылевъ
about.me/majioa

Re: [devel] Policy по упаковке модулей Node.js

[Alexey Shabalin]

пт, 28 февр. 2020 г. в 00:28, Vitaly Lipatov <lav@altlinux.ru>:
>
> Хочу предложить на обсуждение полиси по упаковке модулей для Node.js:
> https://www.altlinux.org/Node.js_Policy
>

В целом нормально.
Есть вопросы:
1)
> Все пакеты npmjs паковать в rpm было бы неправильно, потому что они уже суть упакованные модули для nodejs.
> А вот пакеты для nodejs, использующие нативные библиотеки, паковать нужно обязательно, иначе невозможно обеспечить сборку бинарной части такого пакета.

Что имеется ввиду под "нативные"? библиотеки на c/c++ ?
Если да, то почему в качестве пример выбран node-webpack, в нем нет
бинарных библиотек.

2) Как использовать эти пакеты (sass, node-gyp) при сборке своих пакетов?
Я пока другого способа, как в %prep сделать симлинки, не придумал:
%prep
%setup -q
%patch -p1
ln -sf %nodejs_sitelib/node-gyp node_modules/node-gyp
ln -sf %nodejs_sitelib/node-sass node_modules/node-sass
ln -sf %nodejs_sitelib/npm node_modules/npm

Получается не совсем удобная схема.
Вот собираю я grafana.
запустил в своём бранче
yarn install --pure-lockfile
в получившемся node_modules поудалял node-sass, node-gyp, что бы потом
в %prep сделать симлинки на  системные.
Может есть рекомендации, как это сделать лучше?


-- 
Alexey Shabalin

Re: [devel] Policy по упаковке модулей Node.js

[Vitaly Lipatov]

Alexey Shabalin писал 3.3.20 20:01:
...
>> А вот пакеты для nodejs, использующие нативные библиотеки, паковать 
>> нужно обязательно, иначе невозможно обеспечить сборку бинарной части 
>> такого пакета.
> 
> Что имеется ввиду под "нативные"? библиотеки на c/c++ ?
Да.

> Если да, то почему в качестве пример выбран node-webpack, в нем нет
> бинарных библиотек.
Обновлю примеры. У меня пока не было хороших примеров :)

> 2) Как использовать эти пакеты (sass, node-gyp) при сборке своих 
> пакетов?
> Я пока другого способа, как в %prep сделать симлинки, не придумал:
> %prep
> %setup -q
> %patch -p1
> ln -sf %nodejs_sitelib/node-gyp node_modules/node-gyp
> ln -sf %nodejs_sitelib/node-sass node_modules/node-sass
> ln -sf %nodejs_sitelib/npm node_modules/npm
Зависит от того, как они используются. В идеале лучше не делать ссылки.

> Получается не совсем удобная схема.
> Вот собираю я grafana.
> запустил в своём бранче
> yarn install --pure-lockfile
> в получившемся node_modules поудалял node-sass, node-gyp, что бы потом
> в %prep сделать симлинки на  системные.
> Может есть рекомендации, как это сделать лучше?
Я предлагаю собирать любым способом, чтобы стало понятно, как этом можно 
сделать удобно.

Из изложенного такие выводы:
1. не должны требоваться симлинки в node_modules, node и так отлично 
загрузит эти модули, а скрипты — запустят команды (node-gyp и npm)
2. удаление ненужных модулей сделать важно, а в случае, если там 
бинарники — и необходимо


-- 
С уважением,
Виталий Липатов,
ALT Linux Team