Aetae

Получить корень приложения можно простым трюком:

// если esm
//const _dirname = path.dirname(fileURLToPath(import.meta.url)); 

// просто берём весь путь, и отрезаем его перед первым вхождением node_modules
const appRoot = path.resolve(__dirname).split(/[/\\]node_modules/, 1)[0];

// если esm
// import(appRoot + "/dbconfig.js").then(...);
require(appRoot + "/dbconfig.js");

Я поменял ts на js, т.к. конфиг файл не должен быть ts, если ты делаешь полноценный npm пакет. Потому что полноценный npm-пакет это собранный js, который из ts только декларации оставляет и не умеет импортировать ts.
Если пакет у тебя исключительно под себя, то он может быть и тупо наюбором ts файлов, которые ты будешь у себя подключать и собирать в самом приложении. Тогда импорт ts возможен, но только для тебя, т.к. версий и настроек ts 100500 и практически гарантия, что у кого-то другого оно тупо не заведётся.

Там ещё очень много нюансов будет завязано на полноценно понимание как работает сборщики, что такое ts, и как будет работать конечный код. Если у вас его нет, то будет больно.

Все интерфейсы что должны быть публичными - должны быть экспортированы в корне @company/core, точно также как и все модули.

Подозреваю # в пути лишний.

Ты можешь воспользоваться yarn resolutions для перезаписи зависимостей. Однако следует помнить, что разные мажорные версии (2 и 3 соответственно) могут иметь ломающие различия в api.

Нет, ему пофиг на диски, он ставит всё в папку проекта.
Если ты пройдёшься по вопросам связанным с npm тут(любым) - окажется что проблема в половине случаев - использование "самой новой" версии node js, которую поддерживают чуть менее чем никто.
Твой случай тот же самый. Всегда ставь lts версию node и всё будет (в основном) работать.

Не изменил версию, потому что tar "6.0.2", а не tar "^6.0.2".
А в целом - забейте болт.
1. Большинство уязвимостей находятся в либах, использующихся вами локально для сборки, а сами себя вы ломать будете.
2. Vue исполняется на клиенте и всё эти уязвимости в любом случае не имеют никакого значения, даже если окажутся в рабочем коде.

Внимательней к этому стоит присмотреться только когда начнёте писать сервер на node.js.

P.S. Если очень хочется - можно воспользоваться yarn resolutions и захардпатчить версии зависимостей. Но никто тогда вам не гарантирует корректную работу.

При установке зависимостей этот модуль и так окажется в корне. Если у тебя оказывается две версии одного модуля - одна твоя в корне, другая в подпапке другой зависимости - это плохо и бессмысленно раздувает бандл. Старайся обновлять всё зависимости чтоб такого не было. На крайний случай можно использовать yarn resolutions или установить себе ту же версию что и зависимость.
А по вопросу, если всё таки такое случится - никакой разницы, кроме того что ты это никак не контролируешь.

Ну ошибка жалуется на отсутствие python. Попробуй установить.

Однако подозреваю дело в версии Node, последняя LTS ток неделю как вышла и пакеты могут парить мозги.

Установи пуфон, очевидно же. На большинстве линухов он из коробки, что у тя за дистриб?
Ну и не-lts ноду юзать не рекомендуется, многие пакеты не успевают подтягиваться.

Хз, что за fastify но если он поддерживает и js и ts - может оставить заботу о типах на того, кто захочет использовать ваш плагин(хоть это и моветон).
Если он использует только ts, то используя его, вы, очевидно, должны знать ts. В такому случае сделайте именно то, что вам пишет консоль: сделайте соответствующий файл декларации.