Код-прототип для декоратора пакета capacitor-geolocation

import {DeepClientInstance} from '@deep-foundation/deeplinks/imports/client.js'
import { Package } from './package';

/**
 * 
 * @example
 * #### Create a decorator from another decorator
\`\`\`
const deep = new DeepClient({token: ''});
const anotherDeepDecorator = createAnotherDecorator(deep); // Note that this step is optional and showed only to demonstrate that you can create a decorator from another decorator and have a chain of decorators
const geolocationDeepDecorator = createAdditionalFeatureDecorator(anotherDeepDecorator);
\`\`\`ts
 */
export function createGeolocationDecorator<T extends DeepClientInstance>(deep: T): GeolocationDecorator<T> {
  const _package = new Package({deep});
  return Object.assign({
    ...deep,
    async insertPosition() {
      // TODO: Implement
      throw new Error("Not implemented");
    }
  }, _package);
}

export type GeolocationDecorator<T extends DeepClientInstance> = T & Package & { 
  insertPosition(): Promise<void> 
}

Где генерировать поля под каждую связь

Или же стоит перенести генерацию класса прям сюда, т.е. что бы поля были напрямую тут - я имею в виду под каждую связь используется createEntity в классе Package. Это должно происходить здесь, вместо того класса, и класс Package нужно удалить? Напоминаю как выглядит package класс

Свойство name

И ещё у Package класса было свойство name. Теперь оно будет перезатирываться если использовать решение выше, т.к. декораторы могут друг на друга наслаиваться. Предлагаю это свойство убрать.

Функции и минилинки

И ещё у меня по прежнему диссонанс по поводу функций. Допустим ситуацию: Функция insertDeviceRegistrationToken требует пакет A и B в минилинксах Функция insertPushNotification требует пакет C и D в минилинксах Как это организовать в коде? Сейчас в npm-packager-proxy (хоть он и не прокси, надо его переименовать) экспортируется enum в котором указано какие пакеты требуются для минилинксов, getRequiredPackagesLinks, applyMinilinks (да-да, ты говорил её переименоватть в applyRequiredPackagesToMinilinks или что-то такое, я ещё не дошёл до этих изменений) Вопрос: каким образом это организовать (список пакетов требуемых в минилинксха для каждой функции) если функции будут находиться в объекте, который может иметь несколько функций, описанных выше в примере?

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

Проблема: applyMinilinks функция перезапишется другим декоратором. Этот вариант не подходит (наверно? Есть идеи?). Можно сделать свойство requiredPackagesInMinilinks, которое с каждым декоратором пополняется. А applyRequiredPackagesToMinilinks опирается на это свойство и закидыват в минилнкс нужные связи. Абстрактная проблема-вопрос в моей голове, которая наверно из за недостаточного понимания нашего будущего связанное с версиями: а что, если пакет A требует пакет D@0.0.1, в то время как пакет B треубет пакет D@0.0.2? Текущая идея с этим не справится. requiredPackagesInMinilinks так же должен содержать версию каждого требуемого пакета? У нас сейчас разрешено иметь несколько версий одного пакета? Если нет, то как я установлю два пакета которые требуют один и тот же пакет, но разных версий? Что мы будем с этим делать?

Если нужны требуемые минилинки под каждые функцию - то я полагаю можно и свойство функции присвоить :THINK:

function myFunction() {
}
myFunction.requiredPackagesInMinilinks = []