feat: expose 'svelte/internal'
#10987
Conversation
🦋 Changeset detectedLatest commit: 8311e9c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
| @@ -0,0 +1,5 @@ | |||
| // TODO we may, on a best-effort basis, reimplement some of the legacy private APIs here so that certain libraries continue to work. Those APIs will be marked as deprecated (and should noisily warn the user) and will be removed in a future version of Svelte. | |||
|
|
|||
| throw new Error( | |||
There was a problem hiding this comment.
I vaguely remember @dominikg / @bluwy trying this approach to throw an error for better visibility what's happening, but IIRC the node/bundlers/whatever swallow the error and show something opaque instead.
In general I would prefer if we instead would keep svelte/internal and expose a browser+default condition for the client/server entry points
There was a problem hiding this comment.
The issue people are facing isn't that they're importing this module and it's failing, it's that Vite is attempting to preoptimize stuff based on what vite-plugin-svelte tells it. So there are two possible solutions:
- this one
- vite-plugin-svelte dynamic generates the list of Svelte subpackages from the
package.jsonit finds
Ultimately we need both, but this is what will fix the errors for the largest number of people most quickly
There was a problem hiding this comment.
In general I would prefer if we instead would keep svelte/internal and expose a browser+default condition for the client/server entry points
I really don't think that's the right approach — having different export conditions is a good way to expose a common API across different environments (such as onMount being a no-op in SSR, but still existing), but using it to have the same module specifier mean two completely different modules feels like a recipe for confusion
There was a problem hiding this comment.
Who would be confused by that? It's an internal implementation detail that only concerns us. And doing it this way would mean less configs in the wild that need to be adjusted, which I value way higher.
For a quick fix I agree that this is the best option for now
Fixes #10979 and sveltejs/kit#12056
Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.Tests and linting
pnpm testand lint the project withpnpm lint