svelte/valid-prop-names-in-kit-pages false positives on destructured & renamed props

[james-camilleri]

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. :)

[baseballyama]

closed in #1126.
This issue is fixed in v3.1.0.