fix: improve setup of default export

[benmccann]

closes #8088

@dominikg @bluwy do we still need to export ssr as well? Why does vite-plugin-svelte need the custom logic below? Shouldn't Vite resolve to the ssr or non-ssr version as appropriate using the default export?

https://github.com/sveltejs/vite-plugin-svelte/blob/f8d2bab37e875f654202baeb89d85af9c7501562/packages/vite-plugin-svelte/src/index.ts#L138

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
svelte-dev-2	❌ Failed (Inspect)		Apr 12, 2023 7:41pm

[vercel]

@benmccann is attempting to deploy a commit to the Svelte Team on Vercel.

A member of the Team first needs to authorize it.

[Conduitry]

I seem to recall there being some discussion where we decided the svelte/ssr stuff didn't actually help with treeshaking for SSR, or at least not in the way we were intending, but we couldn't remove it once it was added because it would be a breaking change. Does anyone remember what I might be thinking of?

[dominikg]

To my knowledge this does work as intended, treeshaking imports only used in onMount during ssr.

latest vite does not need the custom resolve for it in v-p-s anymore, but early vite 4 versions did, so we cant remove it without breaking.

please keep the separate ssr export as is for now.
Also remind me to setup svelte ecosystem ci once the modern tooling is in place here.

[bluwy]

I think we can remove the separate ssr export, that was because Vite isn't resolving the node condition correctly before, but it's now fixed. Since they can bump Vite to fix it, I don't think that should block us from removing it.

[dominikg]

Oh, i didn't realize the browser condition above, thanks for pointing it out @bluwy

This would be a very breaking change for everything not understanding the browser exports condition. They got index.js before and now would get ssr.js

[dummdidumm]

I vote for keeping the ssr export around a while longer, it's only a few lines in the package.json so doesn't hurt compared to the pain we would give people not knowing about this stuff

[benmccann]

This would be a very breaking change for everything not understanding the browser exports condition. They got index.js before and now would get ssr.js

What falls into the category of understanding exports, but not browser? I've never seen such a tool

[dominikg]

Any bundler not setting the browser condition explicitly, maybe unpkg or other package cdns? unpkg/unpkg#325

In principle I do agree with simplifying the conditions, and using "node" as synonymous for SSR isn't great.

Another question would be if rollup and webpack configs from users need to be updated to enable the browser condition, i'm not sure it is set by default there.

[benmccann]

I think it's on by default for webpack:
https://webpack.js.org/guides/package-exports/#common-patterns
https://webpack.js.org/guides/package-exports/#target-environment

It's not for Rollup, but we suggest it in the rollup-plugin-svelte docs:
https://github.com/sveltejs/rollup-plugin-svelte#usage

[benmccann]

svelte/ssr is a workaround for a bug in Vite 4.0 that was fixed in Vite 4.1. One option might be to remove svelte/ssr and release a new version of vite-plugin-svelte that uses it only when Svelte 3 is detected in the package.json. Then in the Svelte 4 release notes we can say it's only compatible with the newer version of vite-plugin-svelte which you can also get by bumping to a certain version of SvelteKit where we've bumped the vite-plugin-svelte version.

[benmccann]

this branch is trashed. closing in favor of #8516