Использование сторонних библиотек

• Если библиотека активно развивается и широко используется (например, React), ставим ее через npm/yarn. Периодически обновляем до последней версии и тестируем на совместимость с существующим кодом.
• Библиотека широко используется, но уже не развивается (например, classnames), действуем аналогично предыдущему пункту.
• Автор забросил библиотеку, но она активно развивается в одном из форков (найти такой мы можем с помощью Network diagram на сайте github. Пример: jison). Устанавливаем библиотеку из гит репозитория активного форка с помощью npm. Если промежуточные изменения нестабильны -- устанавливаем стабильную ветвь или определенный коммит. Дополнительно, клонируем себе репозиторий в папку Lib и периодически делаем pull.
• Мы собираемся развивать стороннюю библиотеку. Делаем ее форк в свой аккаунт. Клонируем в папку Lib и ведем разработку в ней. Устанавливаем в проект с помощью npm из гит репозитория своего форка.
• Папка Lib не входит в проекты.
• Не используем git submodule для установки сторонних библиотек внутрь своего проекта. По крайней мере на VS Code наличие сабмодулей загромождает интерфейс панели управления git. Да и удаление сабмодуля из проекта дело хлопотное.

Конкретизируем следующий шаг

1. Есть разбор предложения "покажи всех клиентов из минска". сейчас он рисует дерево, где слова зеленые, а остальные узлы белые.
2. Наша задача: найти сопоставления для сущностей и, там где найдено, мы будем закрашивать узлы дерева красным цветом.
3. Для этого нам понадобится логическая ER модель базы данных.

   Текущая реализация строит ее на основе физической структуры, но это не совсем то, что нам надо. например, в физической модели будет присутствовать таблица GD_CONTACT, хотя такой сущности нет в логической модели, где мы имеем семь сущностей: Папка, Группа, Организация, Банк, Подразделение, Физическое лицо и Сотрудник предприятия.

   Все они базируются на одной физической таблице GD_CONTACT.

4. Предполагается, что мы добавим в БД (в дополнительные таблицы или в существующую таблицу AT_RELATIONS) информацию, которая позволит нам правильно извлекать логическую структуру БД.
5. Причем, если такая информация для таблицы не задана, то мы берем ее физическую структуру и на основе нее создаем сущность в логической модели.
6. Возвращаемся к нашему предложению:

   Сначала мы встречаем существительное "клиентов" -- "клиент" в ед. числе именительного падежа. Через заданный синонимический ряд "клиент - организация" мы можем установить соответствие этого существительного с сущностью "Организация" из логической ER модели базы данных.

7. Переходим к фразе "из минска". Тут возможны несколько вариантов сопоставления.

   а) Мы наделяем слова в нашем словаре семантическими категориями. Например, Минск -- это город, а город -- это место. Ищем в базе данных и находим справочник "Административно-территориальных единиц", а "Административно-территориальная единица" находится в смысловом ряду с городом, местом.

   б) Мы анализируем предлог "из" в предложной фразе "из Минска" и узнаем, что он имеет смысл места. Далее, через смысловой (синонимический) ряд выходим на справочник "Административно-территориальных единиц".

8. Весь анализ должен происходить на клиенте. Т.е. надо подумать о передаче схемы с сервера на клиент, представлении ее в памяти и объектах для работы с ней.
9. На сервере схема должна читаться однократно и храниться в оперативной памяти. Чтобы последующие обращения (покдлючения) клиентов не приводили к повторному длительному чтению всей структуры БД.