Вводим строгие контракты на работу с модулями V4

[kobezzza]

В рамках улучшения работы с кодом и борьбой с круговыми ссылками предлагается ввести следующие правила:

1. Запрещается каким-либо образом изменять прелюдию V4 в слоях. В дальнейшем, мы хотим собирать прелюдию статически и механизмы override не будут работать вовсе.

2. Запрещается переопределять core/ модули в слоях кроме разводящих страниц (например, core/request/engines/index) и интерфейсов (например, core/request/interface). Добавлять новые файлы при этом допускается.

3. Все публичные модули обязаны иметь в своей корневой папке package.json с декларацией опции exports.
   Импортировать что-то из этого модуля, чего нет в exports - нельзя. К компонентам нужно отдельное правило, т.к. там уже есть index.js - надо обсуждать.

4. Компонент должен реэкспортировать все своё public API. Доступ к API компонента должен осуществляться только по импорту главного файла, имя которого совпадает с папкой компонента.

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

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

1. src/config - runtime конфиг.
2. src/lang - языковые пакеты.
3. src/prelude - сюда надо вынести прелюдию.
4. src/core - общая библиотека.
5. src/models - общие дата провайдеры.
6. src/routes - пути приложения (в load функции можно делать динамические импорты на что угодно)
7. src/init - инициализация приложения.
8. src/presets - пресеты для компонентов и приложения.
9. src/components - библиотека компонентов.
10. src/*/core|models|components|pages - неймспейс для подпроектов, например, cb или cps.
11. src/pages - страницы приложения.
12. src/entries - entry файлы сборки.

Изменения модулей:

1. src/core/prelude вынести в src/prelude.
2. src/core/init вынести в src/init.
3. src/core/component/state вынести в src/core/state.
4. src/core/component/client-state вынести в src/core/client-state.
5. src/core/component/event/emitter вынести в src/core/global-emitter.
6. src/core/component/event/providers вынести в src/init.

Для независимых runtime модулей следует размещать их вне "src".
Например, standalone/rum.

Дальнейшие улучшения:

1. Прелюдия должна собираться в отдельный бандл.

[shining-mind]

Предлагаю слой страниц держать отдельно от app. К слову, я описывал текущую структуру в книге, но возможно где-то ошибся https://github.com/V4Fire/TheBook/blob/main/concepts/002-project-structure.md

В этом issue не упомянуто, что делать с произвольными слоями, типа srch, cb и т.д.

[kobezzza]

Предлагаю слой страниц держать отдельно от app. К слову, я описывал текущую структуру в книге, но возможно где-то ошибся https://github.com/V4Fire/TheBook/blob/main/concepts/002-project-structure.md

src/app - само приложение. Сюда должны быть вынесены src/core/init, страницы (например, p-v4-components-demo) и специфичные для конкретного приложения компоненты (это только для самого последнего слоя, например, cb или cps).

--

В этом issue не упомянуто, что делать с произвольными слоями, типа srch, cb и т.д.

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

[gretzkiy]

Запрещается переопределять core/ модули в слоях кроме разводящих страниц (например, core/request/engines/index) и интерфейсов (например, core/request/interface). Добавлять новые файлы при этом допускается.

Запрет вносить изменения в модули core/ не слишком ли жесткое ограничение? В разводящих файлах обычно только реэкспорты конкретного движка из внутреннего модуля. Иногда переопределением движка мы пользуемся для добавления/временного исправления функционала, поэтому может требоваться возможность переопределения не только разводящего файла.

Компонент должен реэкспортировать все своё public API. Доступ к API компонента должен осуществляться только по импорту главного файла, имя которого совпадает с папкой компонента.

По поводу правила для компонентов. Отмечу, что часто для возможности корректного переопределения компонента в дочернем слое он должен экспортировать не только свое публичное апи, но и приватные части. Частый пример - свой symbolGenerator или внутренние хелперы. Мб переопределение компонента детектить линтером в файле дочернего компонента на уровне ast и тогда разрешать любой импорт из родителя?

src/app - само приложение. Сюда должны быть вынесены src/core/init, страницы (например, p-v4-components-demo) и специфичные для конкретного приложения компоненты (это только для самого последнего слоя, например, cb или cps).

Вот тут запутался. В сабже написано, что src/core/init переезжает в src/init, а у страниц остается своя директория. Как все-таки предполагается? В моем понимании, src/app это файлы самодостаточного приложения - рутовая страница и все остальные страницы. При этом отдельные неймспейсы (src/cb, src/cps) могут быть в любом слое, в том числе в самом последнем

[kobezzza]

Запрет вносить изменения в модули core/ не слишком ли жесткое ограничение? В разводящих файлах обычно только реэкспорты конкретного движка из внутреннего модуля. Иногда переопределением движка мы пользуемся для добавления/временного исправления функционала, поэтому может требоваться возможность переопределения не только разводящего файла.

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

По поводу правила для компонентов. Отмечу, что часто для возможности корректного переопределения компонента в дочернем слое он должен экспортировать не только свое публичное апи, но и приватные части. Частый пример - свой symbolGenerator или внутренние хелперы. Мб переопределение компонента детектить линтером в файле дочернего компонента на уровне ast и тогда разрешать любой импорт из родителя?

От реэкспорта symbolGenerator мы давно отказались. А если компонент, что-то реэкспортирует, то значит оно паблик уже.
Тут речь про то, что нельзя писать вне компонента импорты по типу: import 'components/form/b-button/helpers'.

Вот тут запутался. В сабже написано, что src/core/init переезжает в src/init, а у страниц остается своя директория. Как все-таки предполагается? В моем понимании, src/app это файлы самодостаточного приложения - рутовая страница и все остальные страницы. При этом отдельные неймспейсы (src/cb, src/cps) могут быть в любом слое, в том числе в самом последнем

Переезд обусловлены тем, что в src/init могут быть импорты как к /core так и к /models. А вот импортов, к компонентов быть не должно. В новой схеме появилось простое и понятное правило, на которое можно написать линтер. Неймспейс может импортировать только себя и неймспейсы выше себя.

src/app пока на уровне обсуждения, мб и откажемся от него. Но, обрати внимание, что pages вынесли из components/