chore: don't bundle dependencies

[benmccann]

The ecosystem generally expects that dependencies are external. E.g. if there's a security issue, it will get flagged by npm audit if external. If it's bundled then we need to make sure we're raising a security vulnerability against Svelte which bundles a vulnerable version of a library and we're not doing that, which means that all security vulnerabilities in dependencies go unflagged.

This may result in more being downloaded on average. However, many of our dependencies like magic-string, @jridgewell/sourcemap-codec, etc. are already used by other projects like Rollup, svelte-preprocess, etc. For npm users, this will avoid the download cost if the dependency is already used by the project. For users using package managers like pnpm, this is an even bigger win as those dependencies won't need to be downloaded if they are used by any other project you've already installed.

We also avoid generating source maps for these packages when we avoid bundling, which will really shrink the size of the Svelte package. For packages like periscopic which distribute unbundled source, this is a big win as they don't need source maps at all. For packages which have sourcemaps of their own, we don't get that savings, but we could probably convert some of the libraries to this lighter-weight way of being distributed especially if they're ones we control.

[vercel]

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

A member of the Team first needs to authorize it.

[dummdidumm]

It would be great if we didn't need the ESM version at all - just unbundled. Is there something stopping is from doing that?
If there is then that begs the question if it's worthwhile to even do the TS->JSdoc conversion.

[benmccann]

PR for unbundling here: #8613

[Conduitry]

Having the UMD version for the REPL bundle specific versions of dependencies - but having the published package used for consumption everywhere else use prod dependencies with ranges - makes me uncomfortable. Has this been discussed? Is there any way around this? If we still need UMD builds for the REPL, can they live somewhere else besides in the same main package?

[dummdidumm]

This has not been discussed, no, but you make a good point.
What do you mean by "besides the same main package"? A new package like @sveltejs/svelte-precompiled?
What about the CJS output?

[benmccann]

Why is it that we need UMD builds for the REPL? Can it not use ESM? Do we need a bundled version so that it's smaller?

Perhaps we should have a +server.js for the REPL which bundles it at request time and caches the result so that most requests are fast. Then we could have smaller downloads for all our users since they don't need us distributing UMD builds in the npm package.

[dummdidumm]

How would bundling at request time look like? And how would caching look like? svelte/[version]/+server.js, use ISR to cache, use rollup web build to bundle? Will downloading from npm on the server on the fly succeed, given that there may be some fs access or other funky stuff in some of the dependencies which might not work in a deployed environment?

[benmccann]

svelte/[version]/+server.js

sure. doesn't matter what the exact URL is, but that seems fine to me

use ISR to cache

I'm not that familiar with ISR, but if it works then sure. Any file system or object storage would also work

use rollup web build to bundle?

Yes

Will downloading from npm on the server on the fly succeed, given that there may be some fs access or other funky stuff in some of the dependencies which might not work in a deployed environment?

I don't understand. We're not running the dependencies on the server (just bundling them) so why would we care if they access the fs? Also, if they did do that, wouldn't we already be failing at runtime today?

[PuruVJ]

I would not go with +server.js approach as it would bind the REPL with svelte.dev, and not be a standalone component at all.

Precompiled seems like a good idea @sveltejs/precompiled. It does have the issue where a dependency bundled in it may be different version than the esm version for users, but will it cause that many issues if we set a sensible enough semver range for svelte's dependencies?

[MrHBS]

If no bundling is done, why not use tsc directly and get rid of rollup?

[dummdidumm]

Closing in favor of #8613, I merged the package.json changes into it.