fix: report derived_invalid_export for export let x = $derived(...)

[giaBaoJS]

Fixes #15842

In runes mode, export const x = $derived(...) reports derived_invalid_export, which tells you what to do instead. export let x = $derived(...) reports legacy_export_invalid — "Cannot use export let in runes mode — use $props() instead" — which sends you off toward props, when the actual problem is that you are trying to export derived state.

Why it happens

ExportNamedDeclaration throws the legacy error as soon as it sees kind === 'let':

if (
	context.state.analysis.runes &&
	context.state.ast_type === 'instance' &&
	node.declaration.kind === 'let'
) {
	e.legacy_export_invalid(node);
}

That happens before the loop below ever looks at binding kinds, so derived_invalid_export is unreachable for let. const has no such early throw, which is exactly why the const form gets the better message.

The fix

Skip the early export let throw when the declaration binds derived state, so the more specific error below is the one that fires. Everything else keeps the message it had:

source (runes mode, instance script)	before	after
export let x = 5	legacy_export_invalid	legacy_export_invalid
export let x;	legacy_export_invalid	legacy_export_invalid
export let x = $state(0)	legacy_export_invalid	legacy_export_invalid
export let x = $derived(s * 2)	legacy_export_invalid	derived_invalid_export
export let { a } = $derived(o)	legacy_export_invalid	derived_invalid_export
export const x = $derived(s * 2)	derived_invalid_export	derived_invalid_export

On the wording

I deliberately did not invent a new message — this reuses the existing derived_invalid_export text verbatim, so let and const now say the same thing. You said in the issue you weren't sure what the right wording is, and I did not want to pre-empt that; if you'd rather let said something of its own, or the shared message were reworded, I'm happy to change it.

I also left the export const foo = 42 question in your second paragraph alone. That's a separate call about whether exposing plain values on the instance is intended, and it seemed better not to bundle it in here.

Changes

• 2-analyze/visitors/ExportNamedDeclaration.js: guard the early export let throw with a declares_derived() check
• tests/compiler-errors/samples/runes-export-let-derived: export let double = $derived(count * 2) now expects derived_invalid_export

Test plan

pnpm test
#  Test Files  34 passed (34)
#  Tests  7754 passed | 69 skipped (7823)
#  (7753 on main, +1 from the new sample)

pnpm lint                    # clean
pnpm --filter svelte check   # clean

Reverting the ExportNamedDeclaration.js change turns the new sample red and nothing else:

FAIL packages/svelte/tests/compiler-errors/test.ts > runes-export-let-derived
AssertionError: expected 'legacy_export_invalid' to be 'derived_invalid_export'
Tests  1 failed | 146 passed (147)

The existing runes-export-let sample still expects legacy_export_invalid and still passes, so the legacy error has not been weakened — only made to yield when the derived error is the more accurate one.

[pkg-svelte-dev]

Install the latest version of svelte from 814d478:

pnpm add https://pkg.svelte.dev/svelte/c/814d4780809fe5e1dea93d3d45f7f3c4c0eede2c

Open in pkg.svelte.dev: https://pkg.svelte.dev/repos/svelte/pr/18692

Note

This PR is from a fork. A maintainer must approve approve each commit before it can be built and installed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 814d478

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