Description
Before You File a Bug Report Please Confirm You Have Done The Following...
- I have tried restarting my IDE and the issue persists.
- I have updated to the latest version of the packages.
What version of ESLint are you using?
9.22.0
What version of eslint-plugin-svelte
are you using?
3.0.3
What did you do?
I'm not sure if this is actually a false positive or intended behaviour, although it seems a little strange if it's the latter.
Renaming the default Svelte props via destructuring seems to trigger this rule, i.e. let { data: pageData }: { data: PageData } = $props()
throws an error even though the prop being accessed is the default data
prop.
For context, I'm using Sanity.io's useQuery for live data editing, and in order to tidy up the prop names in my main page I've destructured data
and renamed it before passing it into the hook. The purpose of the Sanity.io hook isn't really relevant, the question is about the flagging of the standard JavaScript renaming syntax as an error.
<script>
//...
let { data: pageData }: { data: PageData } = $props()
const query = useQuery<ProductionResult>(
PRODUCTION,
{ slug: $page.params.slug },
{ initial: pageData.initial },
)
let { data } = $derived($query)
//...
</script>
Swapping the rename, i.e. leaving let { data }: { data: PageData } = $props()
as is and then renaming the prop in the $derived to let { data: liveData } = $derived($query)
or something seems to work fine.
What did you expect to happen?
I didn't expect the linter to fail on a standard destructure rename of a correct prop.
What actually happened?
The linter complained even though the "original" prop name is the expected SvelteKit data
prop.
Link to GitHub Repo with Minimal Reproducible Example
https://github.com/james-camilleri/eslint-plugin-svelte-repro
Additional comments
Again, it may be that this is the correct/intended behaviour for the rule – the documentation seems to point it out specifically. If that is case I'm not sure of the rationale behind flagging a standard coding procedure, but go ahead and close the issue and I'll disable the rule. Thanks. :)