Language-tools: Используйте onwarn и другие параметры из svelte.config.js для каждого инструмента

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

Это имеет смысл для таких вещей, как предупреждения. Я не согласен с тем, что все настройки языкового сервера должны считываться с него, что IDE должна предоставлять их и интегрировать с языковым сервером.

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

Причина наличия, возможно, не всех, но некоторой конфигурации для языкового сервера в svelte.config.js заключается в том, что по крайней мере параметры формата обычно настраиваются для каждого проекта. : мышление:

https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode#sveltepluginsvelteformatenable

Параметры форматирования должны быть помещены в файл .prettierrc поскольку расширение использует prettier в сочетании с плагином prettier для выполнения форматирования. https://www.npmjs.com/package/prettier-plugin-svelte

У меня красивее в качестве хука перед фиксацией. Конфигурация находится в package.json .

{
  "prettier": {
    "singleQuote": true,
    "printWidth": 80,
    "plugins": [
      "prettier-plugin-svelte"
    ]
  }
}

Есть ли что-то особенное в более красивом вызове из LS? Или он должен загрузить эту конфигурацию, как обычно? : мышление:

Это тоже сработает. Я хотел сказать, что параметры форматирования не должны быть предметом заботы svelte.config.js .

Я согласен, теперь я не вижу ничего, кроме onwarn чтобы разумно перейти на svelte.config.js .

Больше нечего решать.

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

Меня скорее беспокоит добавление поддержки svelte.config.js к вещам, для которых уже есть хорошо отработанные механизмы конфигурации. В ESLint, например, плагины просто передают объект конфигурации, который уже загружен ESLint. Это может быть результатом слияния нескольких иерархических .eslintrc.js файлы (или JSON файлы, или YAML файлы или содержимое eslintConfig ключей в package.json файлов) и Я не думаю, что ESLint сообщает плагину, где находится какой-либо из этих файлов, поэтому я не знаю, где плагин должен искать svelte.config.js . Существует единый унифицированный способ обработки конфигурации, и ядро ​​ESLint хочет нести за это ответственность.

Итак, решение:

1. Научите мой клиент LS читать файлы конфигурации из рабочей области и передавать конфигурацию в LS, как это делает svelte-vscode .
2. Импортируйте конфигурацию из svelte.config.js и как-нибудь используйте ее в .eslintrc.js . Составьте список с игнорированием и используйте его в обеих функциях или что-то в этом роде.
3. Научите svelte-check загружать конфигурацию из рабочей области.

Похоже, единственное, что стоит изменить, - это svelte-check тогда?

За исключением svelte-check , кажется, что это выполнимо в пользовательской среде. : мышление:

На мой взгляд, кандидатами на согласование onwarn являются: language-server, svelte-check, rollup plugin, webpack plugin.