"Modifiers cannot appear here" in unrelated `export type` when props don't have explicit type

[Tortoaster]

Describe the bug

When not declaring an explicit type for props, it seems type declarations cannot be exported.

Reproduction

This works:

<script lang="ts">
	export type ExampleType = 'A' | 'B' | 'C'

	export interface ExampleProps {}

	const {}: ExampleProps = $props()
</script>

But when I remove the : ExampleProps from const {} = $props(), or when I remove the props line altogether (with or without the accompanying interface), I get this error:

Error: Modifiers cannot appear here.
If this is a declare statement, move it into <script context="module">..</script> (ts)
<script lang="ts">
        export type ExampleType = 'A' | 'B' | 'C'
</script>

(side-note: maybe the error can be updated to show <script module>, as the context tag is deprectated)

The export keyword is highlighted. export function gives no error, which is surprising because the effect of the function may differ between different instances of the component. Thankfully, even if exported, functions cannot be imported from other components, but maybe those should give an error.

Possibly related, this does not work regardless of explicitly typed props:

<script lang="ts">
	const allExamples = ['A', 'B', 'C'] as const;
	export type ExampleType = typeof allExamples[number];
</script>

It gives the same error, but it's valid (though a bit obscure) typescript.

As a workaround, everything works properly in module context (by having separate <script> and <script module> blocks). But since we're also allowed to do export interface Props in normal context, I think it would be more intuitive if anything type-related could be exported in normal context as well (and possibly static functions, readonly consts, etc.), as types are inherently equal across all instances of the component.

Logs

System Info

System:
    OS: Linux 6.14 Ubuntu 24.04.3 LTS 24.04.3 LTS (Noble Numbat)
    CPU: (24) x64 AMD Ryzen 9 7900X 12-Core Processor
    Memory: 23.70 GB / 30.50 GB
    Container: Yes
    Shell: 5.2.21 - /bin/bash
  Binaries:
    Node: 22.18.0 - ~/.nvm/versions/node/v22.18.0/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v22.18.0/bin/yarn
    npm: 10.9.3 - ~/.nvm/versions/node/v22.18.0/bin/npm
    pnpm: 10.13.1 - ~/.nvm/versions/node/v22.18.0/bin/pnpm
  Browsers:
    Chrome: 139.0.7258.127
  npmPackages:
    svelte: ^5.0.0 => 5.38.0

Severity

annoyance

[dummdidumm]

These type exports are always invalid when not within the module script. AFAICT the compiler just ignores them but you cannot import them either so it's of no use.

[Tortoaster]

Importing the export type in the example above works even without module context (as in, neither the code below, nor the definition above use module):

<script lang="ts">
	import type { ExampleProps } from "$lib/components/Example.svelte"

	const props: ExampleProps = {}
</script>

Running check will return proper type errors if ExampleProps contains fields that aren't specified in props above.

[dummdidumm]

Huh, that sounds like a bug in language-tools, more specifically svelte2tsx (though given that it works now I'm wondering how to change this without it being a breaking change). Either way, transfering this to the proper repo.

[jasonlyu123]

export function has a different meaning in the instance script, that's why there isn't an error about it. Ideally, you shouldn't export type from an instance script, but we do have special handling to hoist it, i.e. make it work as if you put it in the <script module>. But the special handling does have its limitations.

[Tortoaster]

Would it be possible to allow hoisting for all types? It would fix the strange workaround for the error above, and may improve ergonomics as allowing some types but not others can be surprising. Alternatively, the documentation that explains how to assign types to props could indicate that exporting the interface should preferably be done in a module script.