-
-
Notifications
You must be signed in to change notification settings - Fork 301
Description
Related to #843, it’s not obvious to me how one should go about integrating eslint plugins for additional file types. In my case I want to use eslint-plugin-svelte to add support for Svelte files, with its Svelte-specific rules added to the default rules that XO defines for general JavaScript. Based on https://github.com/sveltejs/eslint-plugin-svelte#usage, this is the cleanest I could come up with:
import xo from 'xo';
import svelte from 'eslint-plugin-svelte';
import svelteParser from 'svelte-eslint-parser';
import typescriptParser from '@typescript-eslint/parser';
const baseConfigs = xo.xoToEslintConfig([]);
const mergedPlugins = Object.fromEntries(baseConfigs.flatMap(config => config.plugins ? Object.entries(config.plugins) : []));
const mergedRules = Object.fromEntries(baseConfigs.flatMap(config => config.rules ? Object.entries(config.rules) : []));
const svelteConfig = {
files: ['**/*.svelte'],
plugins: {
...mergedPlugins,
svelte,
},
languageOptions: {
parser: svelteParser,
parserOptions: {
parser: typescriptParser,
extraFileExtensions: ['.svelte'],
project: true,
},
},
rules: {
...mergedRules,
...svelte.configs.recommended.rules,
},
};
const xoConfig = [
...baseConfigs,
svelteConfig,
];
export default xoConfig;Reproduction: xo-svelte.zip
Even this feels overly verbose and pretty far from the zero-config goal of XO. This took a few hours of fiddling to come up with, and I’m still not sure there’s not a better version possible; I haven’t tested if this supports Svelte files with <script lang="ts">, or .svelte.js/.svelte.ts files. And it suffers from #843 where XO needs to be run via xo '**/*.{js,mjs,cjs,ts,mts,cts,svelte}' for this to work.
Should a suggested configuration for Svelte be added to the readme? A wiki page? Or perhaps it should be baked into XO proper, like XO already has built-in support for TypeScript and JSX/TSX? There seems to be one canonical eslint plugin for Svelte, so perhaps adding it to XO core is the best solution; and the **/*.svelte glob shouldn’t match anything in non-Svelte projects and so it shouldn’t degrade performance. Likewise for Vue and .vue files.