Множество JS-пакетов в одном репозитории

[PaulMaly]

> Наш репозиторий выглядел примерно так

Так вроде node_modules не принято в репу тащить?

[nailxx]

Да, я не верно сформулировал. node_modules действительно вне репы. Так (упрощённо) выглядит песочница, когда с ней работают. Тот же dist тоже не лежит в репозитории.

Спасибо за замечание.

[vintage]

Вы хорошо описали проблемы, которые мы решили чуть по другому:

1. Файлы ложатся в /имяКомпании/путь/к/модулю/исходник.*.
2. Используются модули обращением к $имяКомпании_путь_к_модулю или $имяКомпании.путь.к.модулю.
3. Соответственно никаких импортов не надо, но если очень хочется, то const алиас = $имяКомпании.путь.к.модулю.
4. К npm-модулям идёт обращение через $node.имяМодуля или $node['имя-модуля'].
5. Любой модуль можно "сбилдить" как для веба, так и для ноды. То есть выполняем npm start имяКомпании/путь/к/модулю и получаем для него бандлы web.js, node.js и package.json, для публикации в npm.

Генерация package.json ещё правда не допилена до конца. Сейчас только выписываются все зависимости попавших в node.js mam-модулей от npm-модулей. Нужно ещё добавить прописывание правильных версий.

В целом, получилось обойтись без babel, webpack и прочих огромных штук — лишь один раз ставится маленький и быстрый сборщик, который транспилирует через typescript и postcss, а бандлит через concat-with-sourcemaps, и в одной кодовой базе можно работать с огромным числом модулей, собирая и деплоя любой из них.

[nailxx]

Хмм… Я правильно понимаю, что вы полностью заменили штатный механизм модулей собственным?

Если так, вы заставляете отказаться от инструментов, которые предполагают работу со стандартными модулями: статические чекеры, там, tree-shake’ры всякие. И для NodeJS бандлить пакет в один файл контрпродуктивно.

[monolithed]

Похоже на обычный DI, тоже ничего криминального не вижу.

[vintage]

Я правильно понимаю, что вы полностью заменили штатный механизм модулей собственным?

И да и нет. Исходники пишутся "в своём формате", а из них собираются бандлы под разные целевые платформы. Для веба — web.js без зависимостей, а для ноды — node.js в формате node-модуля.

статические чекеры

Их можно прикрутить, если надо. Но как правило они не особо полезны. От typescript больше пользы.

tree-shake’ры

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

Типичный модуль выглядит так:

namespace $ {

    export class $acme_server extends $mol_server { // тут сборщик понимает, что предварительно надо подгрузить модуль '/mol/server'
        // ...
    }

}

> И для NodeJS бандлить пакет в один файл контрпродуктивно.

Почему? Наоборот, получается компактный модуль без лишнего мусора, с минимумом зависимостей, который уже не нужно транспилировать (однако сорсмапы, если что, лежат рядом), который крайне быстро устанавливается.

[AllenD13]

А alias вебпака не решают вашу задачу?

У меня например все компоненты подгружаются как

import XXX from 'component/XXX'

Тоже самое actions, reducers, less etc. и никаких относительных путей.

А если еще в корне components сделать index.js вида

import XXX from './XXX'
import YYY from './YYY'

export { XXX, YYY }

то можно в дальнейшем импортить удобно список компонентов через деструктуризацию

import  { XXX, YYY } from 'components'

Особенно помогает уменьшить кол-во строк и визуального мусора, когда импортиш большой список в одном месте (например где-нибудь в роутере).

[nailxx]

В теории решает. Но это фича вебпака. А им билдится только клиентский код.

[AllenD13]

Тоже верно :)

[hellosandrik]

Им можно и backend и отдельные библиотеки билдить, получается не так уж и плохо. Один минус — скорость сборки, но это можно частично обойти правильной конфигурацией webpack. Но в целом же, все равно это все грязные хаки и костыли :(

[justboris]

import { validateProject } from 'xod-core'

Этим импортом вы подключите весь большой пакет xod-core себе в бандл. Для браузерного кода это может быть плохо. Tree-shaking может помочь, но насколько я понял, вы прогоняете исходный код через Babel, так что ES6 модули заменятся на обычные CommonJS, с которыми tree-shaking пока не умеет работать.

Еще приведу пример, как в React-router рекомендуют подключать отдельные модули, если вам не нужен весь роутер целиком:

https://github.com/ReactTraining/react-router/blob/master/docs/guides/MinimizingBundleSize.md

[wa_Nadoo]

Рекомендую использовать не Lerna, а его форк Asini (https://github.com/asini/asini), который гораздо быстрее развивается и более гибкий в настройке. Не обязует размещать все пакеты в папке packages. И по поддержке Yarn там уже начата работа.

[khusamov]

Asini уже кончился(

[vintage]

Зато MAM живее всех живых: https://habr.com/ru/post/456288/

[FlashManiac]

А как решить проблему разлинковывания? Например у нас есть монорепозиторий и мы юзаем lerna. Мы запустили lerna bootstrap и у нас все поставилось и прилинковалось. Но стоит нам сделать npm install <module_name> в каком то проекте из packages то внутри этого проекта в node_modules исчезают линки.