Stats TODOs

[Conduitry]

There are several things we would like to have exposed in stats. The idea is to keep this list updated as new things arise.

• All the exported stuff on the component - and whether each is a module or an instance export - and whether each is a let or a const/function
• What variables have been implicitly declared by the framework ($store stuff, maybe other stuff as well later), and whether each one should be writable in user code. (Maybe we don't need to say whether each is writable, if we will have it be a compiler error from Svelte itself to try and write to them?)
• Which top-level variables are implicitly used without being referenced in the script blocks. (This could mean mentioned in the template, or it could be mentioned via a $store auto-subscription, or maybe other things)

[Conduitry]

Maybe we should have separate lists separate lists of variables for 'things that are referred to in the template' and 'things that are referred to in the template and could be changed via the template' (e.g., bind:). If someone is linting with prefer-const, and they have a instance-level let foo; (which is never explicitly assigned to) and also have bind:value={foo} somewhere, it would be nice if we could avoid showing them a 'this is never changed, it should be a const' message.

[Conduitry]

I was just looking at another part of this - that actions, animations, and transitions do not add their name to template_references. I initially just added component.template_references.add(info.name); to each Node's constructor, but that's not quite correct. Consider the following completely valid code:

{#each array as foo}
	<div use:foo/>
{/each}

We need to add it to template_references only if it's not already in the current scope. warn_if_undefined() already has logic for this - and I think the places where we want to warn if something is undefined are precisely the places where we would want to note the template references.

So, we should fold 'adding stuff to template_references' into warn_if_undefined() and come up with some new name for it.

[Rich-Harris]

IIRC component.qualify takes care of that? It's all a little bit hacky and confusing though

[Conduitry]

component.qualify doesn't seem to really take care of this.

	qualify(name) {
		if (this.hoistable_names.has(name)) return name;
		if (this.imported_declarations.has(name)) return name;
		if (this.declarations.indexOf(name) === -1) return name;

		this.template_references.add(name); // TODO we can probably remove most other occurrences of this
		return `ctx.${name}`;
	}

I believe we need to add name as a template reference regardless of whether it's in this.declarations or this.imported_declarations (and possibly also this.hoistable_names, not sure). We could just bump up the this.template_references.add call to address this.

But the bigger problem is that this code doesn't know anything about the template scope it's being called in. Actions don't currently call qualify, so if we amend the example in my previous comment to

{#each array as foo}
	<div in:foo/>
{/each}

then qualify gets called with 'foo' and it has no way of knowing that that doesn't actually count as a template reference. (Aside: it doesn't look like qualify is called with 'array' though, and I don't know whether that is a problem. Code somewhere else is still adding array as a template reference.)

warn_if_undefined is already called with the template scope, and so we could more easily adapt that to take care of all this. I think we might be able to make that (or whatever end up renaming it to) the only place where we call this.template_references.add.

[Conduitry]

It'd also be nice to be able to note whether each template reference is of a type that could result in its referenced identifier being modified or not. For example, if someone has the prefer-const ESLint rule on, and has

<script>
  let foo;
  let bar;
</script>
{foo}
<input bind:value={bar}>

then we'd like to be able to display an ESLint notice about making foo a const, but we don't want to say anything about making bar a const. We could do this with an additional boolean argument to whatever we end up calling this method. I don't think that belongs in qualify.

[Conduitry]

I appear to have underestimated the number of other things that already touch template_references. At this point I think it would be easiest to just introduce additional sets for the things that are referenced in the template via bind: and via other mechanisms, and expose those in stats.

[Conduitry]

+               if (template_scope && template_scope.names.has(name)) return;
+               this.template_references.add(name);
                if (allow_implicit && !this.instance_script) return;
                if (this.instance_scope && this.instance_scope.declarations.has(name)) return;
                if (this.module_scope && this.module_scope.declarations.has(name)) return;
-               if (template_scope && template_scope.names.has(name)) return;
                if (globalWhitelist.has(name)) return;

This is essentially what I have in warn_if_undefined locally right now. This takes care of a number of things. It does not take care of letting the linter know that $foo is okay to refer to in the behavior scripts if we already have a top-level foo - and it does not distinguish between template references that may or may not result into additional assignments to the variable (to prevent the linter from making incorrect prefer-const complaints about the behavior script).

[Rich-Harris]

I'm thinking something long these lines?

<script context="module">
  const ANSWER = 42;

  export function staticFunction() {}
</script>

<script>
  import { writable } from 'svelte/store';

  const name = writable('world');

  export function instanceFunction(){}
</script>

<h1>Hello {$name}!</h1>
<p>The answer is {ANSWER}</p>

const { stats } = svelte.compile(source, { generate: false });
console.log(stats.vars);

[
  {
    name: 'ANSWER',
    kind: 'const',
    module: true,            // because context="module"
    referenced: true         // because used in the template
  },
  {
    name: 'staticFunction',
    kind: 'function',
    module: true
  },
  {
    name: 'writable',
    kind: 'import',
    named: true,             // as opposed to `default: true` or `namespace: true`
    source: 'svelte/store'
  },
  {
    name: 'name',
    kind: 'const'
  },
  {
    name: '$name',
    kind: 'injected',        // because Svelte created it for us
    referenced: true
  },
  {
    name: 'instanceFunction',
    kind: 'function',
    exported: true           // because it's a prop
  }
]

In time, we could add additional properties if (for example) we wanted to track types and initial values and what-have-you.

Would that give us all the functionality we need around this?

[Rich-Harris]

(In case it wasn't clear, I'm suggesting replacing the current stats.props, stats.imports and stats.templateReferences with these)

[Conduitry]

Would this allow us to distinguish between {foo} references and bind:value={foo} references? This would be nice because if someone had prefer-const set and there were no explicit assignments to it in the script block, then in one of these cases we'd want that to be const and in the other let.