create-svelte TS ESLint config generally complaining about .cjs config files

[jimpala]

Describe the bug
Further to #701, when it comes to the .eslintrc.cjs file generated by create-svelte for TypeScript projects, ESLint is moaning within the .cjs files in the top directory, because .eslintrc.cjs isn't really configured to deal with those files. It's particularly moaning about require() calls in these files.

By default, the only two .cjs files in the top directory are the ESLint and Svelte configs, but given it seems to be the convention that any other config files have a .cjs extension (e.g: tailwind.config.cjs and postcss.config.cjs added by svelte-add tailwindcss), you get complaints for these config files too.

I'd guess there were a few ways round this:

1. Change ignorePatterns in .eslintrc.cjs to glob all .cjs files ['*.cjs'] so that ESLint by default ignores these config files entirely.
2. Add appropriate overrides to .eslintrc.cjs such that any .cjs files are parsed correctly.
3. Leave it to the end user to tweak their config 😄

Thanks 🙃

Logs
The sorts of ESLint errors one would expect for the TS parser looking at JS, and also for the ESLint config not having env set to "node".

In svelte.config.js:
ESLint: 'require' is not defined.(no-undef)
ESLint: Require statement not part of import statement.(@typescript-eslint/no-var-requires)

Similar ESLint complaints in tailwind.config.cjs and postcss.config.cjs when svelte-add is used.

To Reproduce

1. Install SvelteKit in the usual way (npm init svelte@next), enabling TypeScript and ESLint for the project.
2. Enable ESLint checks in your editor.
3. Observe red squiggles for the ESLint rules in the files above!

Expected behavior
Nein red squiggles for the ESLint rules in the files above!

Information about your SvelteKit Installation:

System:
    OS: macOS 11.2.3
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 854.33 MB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 15.12.0 - ~/.nvm/versions/node/v15.12.0/bin/node
    Yarn: 1.22.5 - ~/.yarn/bin/yarn
    npm: 7.6.3 - ~/.nvm/versions/node/v15.12.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Browsers:
    Chrome: 89.0.4389.90
    Chrome Canary: 91.0.4459.0
    Firefox: 77.0.1
    Safari: 14.0.3
  npmPackages:
    @sveltejs/kit: next => 1.0.0-next.61 
    svelte: ^3.29.0 => 3.35.0 

Severity
It's not severe - you can just edit the config defaults, but might want to give it some thought 😄

[dummdidumm]

Good observation, did not think about that. All these config files need to be .cjs for now because they do not support ESM yet.

Do you know how option 2 could look like? What would be needed to add such an override? To me that option feels superior to 1, but if there is no easy way I can live with option 1 just as well.

[jimpala]

So I've just whacked open a PR for option 1 for a quick fix! Then I'll share my own config that sort of implements option 2 (which could definitely be improved upon lol).

[jimpala]

module.exports = {
	root: true,
	parser: '@typescript-eslint/parser',
	extends: ['eslint:recommended', 'prettier'],
	plugins: ['svelte3', '@typescript-eslint'],
	ignorePatterns: ['.eslintrc.js'],
	overrides: [
		{ files: ['*.svelte'], processor: 'svelte3/svelte3' },
		// For *.cjs, set env to node to remove the require() complaints.
		{ files: ['*.cjs'], env: { node: true } },
		// Enable the TS rules here instead, so the *.cjs override doesn't inherit them.
		{ files: ['!*.cjs'], extends: 'plugin:@typescript-eslint/recommended' }
	],
	settings: {
		'svelte3/typescript': require('typescript')
	},
	parserOptions: {
		sourceType: 'module',
		ecmaVersion: 2018
	}
};

So this is what I've got in my project - it provisionally works okay, but it's not a particularly pretty config because I don't believe you can 'unextend' any extensions provided beforehand in your overrides. Therefore I've had to move the extension of 'plugin:@typescript-eslint/recommended' from the top level of the object into its own override.

Wondering if there's a neater way, will have a think 🙃

[ignatiusmb]

Thanks for the fix! I'll go ahead and close this as this isn't a problem anymore in the newer templates