[fix] do not generate unused-export-let inside <script context="module">

[rgossiaux]

Fixes #7055

I think this might be the best way to fix the linked issue, and I think it's a reasonable change. Since code inside <script context="module"> is basically just regular JS, warnings like this can be delegated to userland tools--I don't think it needs to be the Svelte compiler's business especially when these compiler warnings cannot be ignored inline.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with [feat], [fix], [chore], or [docs].
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with npm test and lint the project with npm run lint

[dummdidumm]

I tend to agree with this change, but I don't know how other maintainers feel about it

[bluwy]

Makes sense to me.

[benmccann]

Here's a quick summary of the issue. When you do export enum Foo {} in TypeScript it gets converted to:

export var Foo;
(function (Foo) {
})(Foo || (Foo = {}));

The Svelte compiler then gives a warning that var is used rather than const.

I don't see any way to get TypeScript to generate const rather than var

Separately, it also seems that the warning may be broken and giving false positives even outside of using TypeScript: https://svelte.dev/repl/6650478bb7fc474f8c43f82c92694b76?version=3.46.4

I guess my only question would be what happens in the non-TypeScript case. Can we have eslint, svelte-check, or VS Code suggest to the user that they're not using const when they could be?

[benmccann]

https://github.com/sveltejs/eslint-plugin-svelte3#features says it handles script blocks and @rgossiaux reported that https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-mutable-exports.md worked. That's good enough for me

[rgossiaux]

I did a deeper dive on exactly what's going on here. You can see in this REPL that this warning seems to be generated for every export let inside a module script, regardless of whether it is in fact unused, so this actually extends beyond the narrow TypeScript motivation that inspired the PR.

From this code:

svelte/src/compiler/compile/Component.ts

Lines 176 to 186 in 9b7b814

	this.walk_module_js();
	this.push_ignores(this.ast.instance ? extract_ignores_above_position(this.ast.instance.start, this.ast.html.children) : []);
	this.walk_instance_js_pre_template();
	this.pop_ignores();
	this.fragment = new Fragment(this, ast.html);
	this.name = this.get_unique_name(name);
	this.push_ignores(this.ast.instance ? extract_ignores_above_position(this.ast.instance.start, this.ast.html.children) : []);
	this.walk_instance_js_post_template();

You can see that the compiler first checks the module JS, then the instance JS, the template, and finally the instance JS again. Since the module JS is processed first before everything else, it doesn't know about any references in the other parts, so referencing something in the instance script doesn't actually affect whether it's considered "unused" for the purposes of this warning. As for references inside the module script, as far as I can tell, the compiler doesn't actually process them (after all, there's no need to; it's just normal JS). I confirmed with the varsReport compiler option that references inside the module script do not set the variable as referenced.

In short, this unused-export-let check doesn't work at all inside <script context="module">; it effectively just generates a (misleading) warning any time you have export let or export var inside a module script. If that's the behavior you want, you can use this ESLint plugin, but I don't think this was ever intentional.