search

enb / enb-bem-i18n

BEM internationalization for ENB
Other
8 stars 7 forks source link

Split package #60

Closed blond closed 9 years ago

blond commented 9 years ago
tadatuta commented 9 years ago

Как много копипаста окажется между такими пакетами?

tormozz48 commented 9 years ago

Что-то мне не нравится такая идея

tormozz48 commented 9 years ago

Сейчас у нас все про локализацию в рамках одного пакета, а так будет разбросано по 4-м. С таким же успехом можно засунуть обратно *-i18n технологии в соответствующие пакеты по критерию шаблонизаторов

blond commented 9 years ago

Как много копипаста окажется между такими пакетами?

Кажется, что нисколько. Они все будут явно зависить от enb-bem-i18n и от своего пакета, доопределяя и то и другое.

blond commented 9 years ago

Сейчас у нас все про локализацию в рамках одного пакета, а так будет разбросано по 4-м

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

Сейчас пакет явно зависит от всех пакетов про шаблонизацию. Как только нам нужно будет сделать мажорное изменение в одном из них — нам придётся делать мажорное изменение и в этом пакете. Это ещё и означает, что пользователю будут приезжать лишние зависимости.

Кроме того если по каким-то причинам нужно будет для одного шаблонизатора один i18n, а для другого — другой (например, нужны разные версии). То сейчас мы этого просто не сможем сделать.

Ещё у нас есть другие шаблонизаторы: priv-js, bh-php и т.д. Для каждого из них ведь тоже придётся делать технологии в этом пакете. Из-за этого две предыдущие проблемы станут более остро.

Если же разделить код по своим пакетам из минусов вижу только небольшие дополнительные расходы на поддержку.

tadatuta commented 9 years ago

если удастся избавиться от копипаста и enb-bem-i18n будет ставиться по зависимостям прозрачно для пользователя — я за разделение

arikon commented 9 years ago

На мой взгляд ок. Только давайте пакет enb-bem-i18n и шаблонизаторы не подключать по peerDependencies. Это очень больно.

blond commented 9 years ago

@arikon, с шаблонизаторами понятно. А вот с enb-bem-i18n не очень.

Сейчас технологии обёртки на вход требуют собранный файл кейсетов, который собирает keysets-технология из enb-bem-i18n.

Какие мысли как это разрулить? У каждого такого пакета делать технологию keysets (можно без копипаста просто отнаследовать)?

arikon commented 9 years ago

@blond Пусть используют технологию keysets из enb-bem-i18n. Результаты keysets же нужны не только шаблонизаторам, но и js, priv.js.

blond commented 9 years ago

Пусть используют технологию keysets из enb-bem-i18n

Всмысле пользователи отдельно ставят enb-bem-i18n? Тогда как гарантировать нужную версию кроме как через peerDependencies?

arikon commented 9 years ago

С переходом на npm@3.x даже при условии peerDependencies пользователям явно придётся ставить enb-bem-i18n.

Прям очень хочется гарантировать нужные версии? С учётом вашей любви к абсолютно строгим зависимостям мне страшно представить, во что это выльется =)

Если зависимость будет вида ^1.0.0 (и будет апдейтиться по мере выпуска мажорных версий технологий без изменения формата файла), то можно попробовать.

blond commented 9 years ago

С учётом вашей любви к абсолютно строгим зависимостям мне страшно представить, во что это выльется =)

Для peerDependencies у нас нет любви к строгим версиям :)

Если зависимость будет вида ^1.0.0 (и будет апдейтиться по мере выпуска мажорных версий технологий без изменения формата файла), то можно попробовать.

Да, расчёт примерно на это.

tormozz48 commented 9 years ago

Перенес код связанный с шаблонами в:

Осталось убрать его из основного пакета enb-bem-i18n