fix: dynamic namespace fixes and enhancements #11219
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #10006 we added more elaborate mechanisms to determine which namespace a given element is in. For
<svelte:element>
we added a "can't know at compile time" case and introduced a limited heuristic into the runtime.This doesn't work for a few reasons:
The last point is the crucial one: In Svelte 4, we're falling back to the component namespace if we can't know statically - e.g. if someone added
<svelte:options namespace="svg">
then<svelte:element>
should fall back to that namespace instead.We were not doing that up until now, which introduced a regression. Fixing this also means getting rid of the (flawed) "can't know statically" heuristic.
Fixes #10858, though for a complete solution we need some way to tell
<svelte:element>
the namespace at runtime through a special attribute. I chose thexmlns
attribute for that like we do in the static case. So if you set that<svelte:element>
will use that to get the namespace.Before submitting the PR, please make sure you do the following
feat:
,fix:
,chore:
, ordocs:
.Tests and linting
pnpm test
and lint the project withpnpm lint