Language-tools: Utilice onwarn y otras opciones de svelte.config.js para cada herramienta

Los machos tienen sentido para mí. Me imagino que la parte difícil será acordar el nombre / cómo se debe especificar exactamente

Tiene sentido para cosas como las advertencias. No estoy de acuerdo con que todas las configuraciones del servidor de idiomas deban leerse, que debe ser responsabilidad del IDE proporcionarlas e integrarlas con el servidor de idiomas.

Entonces, ¿usar onwarn en su forma actual es una dirección aceptable a seguir?
Para ser compatibles con las configuraciones existentes, podríamos implementar una interfaz de devolución de llamada onwarn similar para interceptar advertencias como se hace actualmente en complementos esbeltos para paquetes.

La razón para tener tal vez no todas, pero alguna configuración para el servidor de idiomas en svelte.config.js es que al menos las opciones de formato generalmente se configuran por proyecto. :pensando:

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

Las opciones de formato deben colocarse en un archivo .prettierrc ya que la extensión hace uso de más bonito en combinación con un complemento más bonito para lograr el formateo. https://www.npmjs.com/package/prettier-plugin-svelte

Lo tengo más bonito como un gancho previo al compromiso. La configuración está en package.json .

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

¿Hay algo especial en una invocación más bonita del LS? ¿O debería cargar esta configuración como suele hacerlo? :pensando:

Esto también funcionará. Mi punto fue que las opciones de formato no deberían ser la preocupación de svelte.config.js .

Estoy de acuerdo, ahora no veo nada más que onwarn para pasar razonablemente al svelte.config.js .

No queda mucho por decidir.

¿Hacer la devolución de llamada onwarn en cada herramienta suena como una buena solución?
Configuración unificada compatible con la actual de los bundlers.

Estoy bastante preocupado por agregar soporte svelte.config.js a cosas que ya tienen mecanismos de configuración bien establecidos. En ESLint, por ejemplo, a los complementos simplemente se les pasa el objeto de configuración que ESLint ya ha cargado. Esto podría ser el resultado de la fusión de varios archivos .eslintrc.js jerárquicos (o archivos JSON, o archivos YAML, o el contenido de las claves eslintConfig en package.json archivos), y No creo que ESLint le diga al complemento dónde estaba alguno de estos archivos, por lo que no sé dónde debería buscar el complemento svelte.config.js . Existe una única forma unificada de manejo de la configuración, y el núcleo de ESLint quiere ser responsable de ello.

Entonces la solución es:

1. Enséñele a mi cliente LS a leer archivos de configuración desde el espacio de trabajo y pasar la configuración al LS como lo hace svelte-vscode .
2. Importe la configuración de svelte.config.js y úsela en .eslintrc.js alguna manera. Haga una lista con ignorados y utilícela en ambas funciones o algo así.
3. Enseñe a svelte-check a cargar la configuración desde el espacio de trabajo.

¿Parece que lo único que vale la pena modificar es svelte-check entonces?

Aparte de svelte-check , parece que es factible en el área de usuario. :pensando:

Los candidatos para la armonización de onwarn en mi opinión son: servidor de idiomas, svelte-check, plugin rollup, plugin de paquete web.