Language-tools: Use onwarn e outras opções de svelte.config.js para cada ferramenta

Os machos sentem para mim. Eu imagino que a parte difícil será concordar em nomear / como exatamente deve ser especificado

Faz sentido para coisas como avisos. Não concordo que todas as configurações do servidor de linguagem devam ser lidas a partir dele, que deve ser responsabilidade do IDE fornecê-las e integrá-las ao servidor de linguagem.

Então, usar onwarn em sua forma atual é uma direção aceitável a seguir?
Para ser compatível com as configurações existentes, poderíamos implementar uma interface de retorno de chamada onwarn semelhante para interceptar avisos como é feito atualmente em plug-ins esbeltos para bundlers.

A razão para ter talvez não todos, mas alguma configuração para o servidor de idioma em svelte.config.js é que pelo menos as opções de formato são geralmente configuradas por projeto. :pensamento:

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

As opções de formatação devem ser colocadas em um arquivo .prettierrc pois a extensão faz uso de mais bonito em combinação com um plugin mais bonito para realizar a formatação. https://www.npmjs.com/package/prettier-plugin-svelte

Eu tenho mais bonito como um gancho pré-commit. A configuração está em package.json .

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

Existe algo especial na invocação mais bonita do LS? Ou ele deve carregar essa configuração como normalmente faz? :pensamento:

Isso vai funcionar também. Meu ponto é que as opções de formatação não devem ser a preocupação de svelte.config.js .

Eu concordo, agora não vejo nada além de onwarn para mover razoavelmente para svelte.config.js .

Não há muito o que decidir.

Fazer onwarn callback em todas as ferramentas parece uma boa solução?
Configuração unificada compatível com a atual nos bundlers.

Estou bastante preocupado em adicionar suporte svelte.config.js a coisas que já têm mecanismos bem estabelecidos para configuração. No ESLint, por exemplo, os plug-ins recebem apenas o objeto de configuração que o ESLint já carregou. Isso pode ser o resultado da fusão de vários arquivos hierárquicos .eslintrc.js (ou arquivos JSON, ou arquivos YAML, ou o conteúdo das chaves eslintConfig em package.json arquivos), e Não acho que o ESLint diga ao plug-in onde qualquer um desses arquivos estava, então não sei onde o plug-in deve procurar por svelte.config.js . Há uma única maneira unificada de lidar com a configuração, e o núcleo ESLint quer ser responsável por ela.

Portanto, a solução é:

1. Ensine meu cliente LS a ler arquivos de configuração da área de trabalho e passar a configuração para o LS como svelte-vscode faz.
2. Importe a configuração de svelte.config.js e use-a em .eslintrc.js alguma forma. Faça uma lista com ignora e use em ambas as funções ou algo assim.
3. Ensine svelte-check a carregar a configuração da área de trabalho.

Parece que a única coisa que vale a pena modificar é svelte-check então?

Além de svelte-check , parece que pode ser feito no userland. :pensamento:

Os candidatos à harmonização de onwarn, na minha opinião, são: servidor de linguagem, verificação svelte, plugin rollup, plugin webpack.