да, этот пакет использует стандартный способ - исходники и поле svelte в package.json

видимо)

короче видимо надо еще раз систематизировать подходы

видно да - и собирается вметсе со всем приложением

вот это в package.json?

"main": "dist/svelte-router.umd.js",
  "module": "dist/index.js",
  "svelte": "dist/index.js",
  "types": "dist/index.d.ts",

Сорян, что надоедаю, прост хочу разобраться

ПОДХОД 1 (рекомендованный в данный момент):

1) сборка и компиляция компонента (пакета) происходит ТОЛЬКО для НЕ свелт приложений.
2) поэтому компилируется либо в файл содержащий инлайном весь сорс код, например чтобы подключить его через CDN к ванилла проекту ввиде JS класса/виджета
3) либо в ESM пакет со скомпилированным компонентом и импортами, которые доверенно резолвить самому браузеру
4) отдельно в package.json указано поле svelte в котором лежит путь к файлу, который должен использоваться для импорта в рамках svelte проекта и обычно там лежат просто исходники или js файлы экспортирующие исходники

этот подход имеет много плюсов, но и главный минус за который так уцепился Александр и тыкает им во все без раздумий - если пакет/компонент имеет препроцессинг, то при использовании в свелт проекте, сборщик проекта придется дополнительно настраивать под КАЖДЫЙ такой пакет.

почему? потому что п.4

Ага. Понятно.

Остаются 2 вопроса: независимый препроцессинг для импортируемого в svelte проект компонента и импортируемый рантайм...

ПОДХОД 2 (рабочий в данный момент):

1) обходим минусы предыдущего подхода используя стандартный подход NPM пакетов с любым другим препроцессингом (scss, ts, etc)
2) заранее прекомпилируем компонент в js
3) чтобы код НЕ дублировался, нужно настроить сборщик так, чтобы импорты НЕ инлайнились в js файл компонентов
4) в этом случае свелт компонент будет выглядеть так как во вкладке JS Output в REPL:

import { ... } from 'svelte/internal';
import { ... } from ...
...
function instance() {}
...
function create_fragment() {}
...
class Component extends SvelteComponent {...}
...

5) в этом случае мы получаем с одной стороны ванильный js код и все препроцессоры УЖЕ произошли. С другой стороны импорты предлагается резолвить уже сборщику проекта, а значит он сможет их оптимизировать между компонентами, включая в бандл один раз.

Благодарю за систематизацию👍🏻 вроде ясно теперь

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

это еще не все)

Ок

Итак, что мы имеем 2 аспекта:
1) собирать одним компилятором весь проект - хорошо, НО
2) настраивать при этом сборщик под каждый пакет - плохо

Угу...

ПОДХОД 3 (пока НЕ работает и потребует значительных доработок плагина сборщика):

1) учим плагины сборщика учитывать таки svelte.config файлы
2) при сборке каждого пакета подсовываем в компилятор настройки идущего с ним svelte.config файла, либо дефолтного если его нет

получается что проект собирается одним компилятором, но при этом настройки компилятора каждого пакета ищут вместе с ним, также как и модули, необходимые для этого