breaking: deprecate context="module" in favor of module

[dummdidumm]

Also reserve a few attributes, which we may or may not use in the future

closes #12637

Making this change revealed that we're currently adding another copy of Svelte 5 to our root node_modules, because the eslint and prettier plugin depend on it, don't find a dependency and then presumably have installed it. By adding an explicit dependency on our workspace version of Svelte to the root this is resolved.

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: 9e62141

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

[Conduitry]

How are we deciding which other attribute names to reserve? Where was that discussed?

[Rich-Harris]

I think it's just the stuff that was mentioned in #12637. Are there others you have in mind, or are you thinking we need to hold off on this until it's percolated a bit more?

[Conduitry]

I don't know. I know you hated using $-prefixed attributes, but purposefully putting ourselves in a situation where we need to predict the future makes me nervous.

[Rich-Harris]

My basic position is this — #12637 (comment) — that we haven't worried about this in the past when we've added lang and generics (and it would be very weird to either a) have those be inconsistent with other special attributes, or b) change them to $lang and $generics), and the cases where people are adding new attributes are rare enough that it's probably fine.

One thing we could do is refuse to accept any attribute that we didn't define — in that case, if someone does add something like pathname so that a preprocessor can do something with it, that same preprocessor is responsible for removing it before Svelte sees it.

[dominikg]

are preprocessors able to remove attributes? we had issues with that in the past iirc.
and it would not solve collision problems as users can't use one attribute for 2 things.

if we are really going to phase out/redesign preprocessing sooner rather than later a generic "don't use common names, ideally prefix with your preprocessor name" should be enough, doesn't have to be hardcoded/validated

[Rich-Harris]

are preprocessors able to remove attributes?

AFK so can't check but I thought we explicitly added this ability so that (for example) TS code wasn't transpiled twice if you were (e.g.) packaging a component - the consumer of the packaged/transpiled version shouldn't see lang="ts"

[Conduitry]

It should work. The docs say it does.

script and style preprocessors can optionally return a record of attributes which represent the updated attributes on the script/style tag.

Saying that unknown attributes are disallowed and that it's a preprocessor's job to remove them makes me a lot more comfortable, if we think people will be okay with that.

[dummdidumm]

For me this is a case of being strict for strictness sake - as Rich said, we didn't worry about it in the past and there have been no known issues with that. It's not like we add these things every day.

[Rich-Harris]

So do we make unknown attributes an error or just a warning? An error would make us bulletproof from a breaking change perspective, but might be annoying in the short term until preprocessors can be updated.

[dummdidumm]

Personally I just would merge this, i.e. not warn not error 😅 if everyone else wants to future proof this more, then a warning

[Rich-Harris]

I'd have more peace of mind with a warning honestly — updated the PR

[Conduitry]

I still see the use of a list of reserved attributes - is the idea that those would still be an error, but other unknown ones would just be a warning? A warning sounds like a good compromise. I'm not going to die on the hill of demanding that this is always a compiler error.

[Rich-Harris]

Exactly:

[xeho91]

Wasn't this supposed to be e.script_invalid_context(attribute);?

[Rich-Harris]

yes! good spot, thanks — #12973

[pooledge]

Cannot export from a svelte component anymore:

Error: Module '"$components/Component.svelte"' has no exported member 'myFn'. Did you mean to use 'import myFn from "$components/Component.svelte"' instead? (ts)

at the same time A component cannot have a default export

[dummdidumm]

Please provide a reproduction

[pooledge]

<script lang="ts" module>
	export function myFn(param: string) {
		return param + "pam" + "pam"
	}
</script>

then

import { myFn } from '$components/Component.svelte'

[Rich-Harris]

This looks like a language-tools issue @dummdidumm — it works, but VS Code doesn't know that it works

Opened an issue over there sveltejs/language-tools#2472

[pooledge]

svelte-check fails in particular, but yes also VSC