Closed EmilTholin closed 5 years ago
While this was required in v2, shouldn't this be removed from v3? While it does eventually catch actual errors, wouldn't this better fit linters? Assuming global knowledge seems a bit overzealous from the compiler.
I'd have to do some thinking about how to support that with the way eslint-plugin-svelte3 is currently written. Right now, all of the linting messages that it presents outside of the script block are just passed-along warnings from the Svelte compiler. So, yes, I think there is an argument for this being the responsibility of the linter (at which point you could define your own globals, specify whether this would be a warning or an error, etc) but the official tooling for that isn't ready for that yet.
@Conduitry how does eslint-plugin-svelte3
deal with the script code? Could expressions in attributes eventually be handled the same? Or is this going to require some large changes?
I ask because while that doesn't happen, maybe we could get Svelte to emit the same warnings for the script blocks? It'd at least be consistent since both have access to the same globals.
It does require some medium-size changes, but I made a lot of them already yesterday 😁 I'm going to need the PR for exposing svelte.walk
to be released in a tagged version, and then I have to tidy some stuff up, and then I'll be ready for an initial version of experimental opt-in linting of expressions in the template.
Using
alert
,prompt
orconfirm
in an inlined event handler gives a warning like'alert' is not defined. Consider adding a <script> block with 'export let alert' to declare a prop
. REPL