fix: hoist imports on top

[paoloricciuti]

Svelte 5 rewrite

Closes #13081

Initially i thought of having a separate hoisted array that put everything higher up but i think that would become confusing very quickly...this will sort the body to put every import on the top so that if you reference it it will actually be available. Personally i think it's good enough but you guys tell me.

Please note that the Svelte codebase is currently being rewritten for Svelte 5. Changes should target Svelte 5, which lives on the default branch (main).

If your PR concerns Svelte 4 (including updates to svelte.dev.docs), please ensure the base branch is svelte-4 and not main.

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 and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

🦋 Changeset detected

Latest commit: d908861

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[dummdidumm]

Thought about the other option (introducing a separate state.imports array) but concluded this is fine and possibly even a bit more robust to future changes

[Rich-Harris]

This isn't safe — I'm going to revert it

[paoloricciuti]

This isn't safe — I'm going to revert it

This could be fixed by returning 0 instead of -1...however if we can fix the upstream bug in vite we can remove code anyway.

[paoloricciuti]

Also wait...i can't seem to reproduce your bug 🤔

[Rich-Harris]

This could be fixed by returning 0 instead of -1

It doesn't work like that — 0 doesn't mean 'preserve the original order', it means 'the order is undefined'. I've learned this the hard way which is why I was able to immediately spot the bug!

Also wait...i can't seem to reproduce your bug

That's because the sort order is engine-dependent — something that yields the desired results in Chrome might fail in Firefox and vice-versa

[paoloricciuti]

That's because the sort order is engine-dependent — something that yields the desired results in Chrome might fail in Firefox and vice-versa

🤯🤯🤯 TIL

[7nik]

the sort order is engine-dependent

However, since ES10 / ES2019 specs require the sorting to be stable if the comparator is consistent (in this PR, it isn't):

The sort must be stable (that is, elements that compare equal must remain in their original order).

ES2019 docs

MDN - look at the stable sorting row.

There is a number of conditions when the order becomes "implementation-defined", but for ordinary arrays, only the comparator consistency and pureness of all involved methods matter.