Let Snowpack bundle the frontend

[benmccann]

Is there a reason we need to embed Rollup to bundle the frontend?

kit/packages/kit/src/api/build/index.js

Line 107 in 0e45255

const client_chunks = await rollup({

Will SnowPack plugins, etc. still work with the approach? I'm assuming you can't use Snowpack's production build pipeline with this. Or if you could I'm not sure which order the builds would execute and one of them would be operating on an already bundled set of JS

[Rich-Harris]

Rollup runs after snowpack build has already taken place, so non-optimisation plugins should work fine. svelte-kit build expects to find the relevant entry points, so an improperly configured optimisation plugin would break things.

It's not as simple as adding our own optimisation plugin to the base config, since svelte-kit build is also doing analysis of the client-side bundles so that the server can inject the correct <link> elements etc. I think it's better if we continue to own this step.

[benmccann]

Thanks for the explanation.

I wonder if we could create a SvelteKit manifest generation plugin for Snowpack or Rollup. We need to be able to map from the input route component to the chunk it ends up in and so we do have to hook into the build system somehow. Making a plugin seems like it would accomplish that without us having to take over all responsibility for the build system.

There's a couple things I think we might be able to accomplish with this:

• Users could utilize other build systems like Webpack, Parcel, etc. for the production bundling step if the community contributed a plugin. The code would be better separated in this case than we have in Sapper today where Sapper needs knowledge of the bundler
• Expert users would have more control over the building. There are some people that want to insert an extra plugin in the build process, etc. that are unable to do so today
• There are multiple bugs in Sapper and SvelteKit's CSS handling. As much as I'd love to get them all fixed I think in some cases having an escape hatch to Webpack or a different Rollup CSS handling is the more expedient solution. Writing a CSS build tool is extremely complex. rollup-plugin-css-chunks doesn't have any tests in it's own repo. We have some in Sapper, but really the plugin itself should be tested directly. And probably the CSS injection plugin should be it's own project. I'm not sure how much we want to be responsible for building out a whole Rollup CSS ecosystem

[Rich-Harris]

Users could utilize other build systems like Webpack, Parcel, etc. for the production bundling step if the community contributed a plugin

Why?

Configurability isn't a goal, it's a means to an end. The factors that go into picking a bundler are a) quality of output, b) speed, c) availability of plugins, d) usability, etc. Usability isn't a concern when the tool is being invoked on your behalf. Plugins are irrelevant when you're dealing with post-Snowpack vanilla JS. Rollup and esbuild are tied on quality of output, webpack and Parcel are behind. In an ideal world we'd be able to use esbuild since its performance is so much better than Rollup, but things like code-splitting are still experimental, and I'm not well-versed enough to know if we'd be able to do the analysis and import rewriting that we need to do. So for now, there's only one sensible option for the optimisation step, and that's Rollup.

Expert users would have more control over the building. There are some people that want to insert an extra plugin in the build process, etc. that are unable to do so today

Can you give an example?

There are multiple bugs in Sapper and SvelteKit's CSS handling. As much as I'd love to get them all fixed I think in some cases having an escape hatch to Webpack or a different Rollup CSS handling is the more expedient solution.

If there are bugs, we should fix them. By abdicating our responsibility to make this work out of the box, we're not adding flexibility, we're adding complexity and fragmentation, and adding to users' burdens. If the current Rollup plugins aren't up to our standards then we can certainly roll our own.

[benmccann]

Can you give an example?

sveltejs/sapper#560 is one. I haven't looked that closely at it. Maybe they could write a preprocessor or it's not a usecase we want to support, but I expect we'll get more requests like this

If there are bugs, we should fix them... If the current Rollup plugins aren't up to our standards then we can certainly roll our own

I agree we should make things work out of the box. At the same time, I worry about how much we might be taking on by writing our own CSS support for Rollup. The more areas we're forging new ground and writing our own plugins the more we'll be relying on implementations that aren't battle-tested and the more code we'll have to maintain in the long-run

I just sent a fix for sveltejs/sapper#1564 and am also taking a look at the fix for sveltejs/sapper#1660. I worry how many others there might be that we haven't discovered yet, but I guess we can try to get those fixed and see what else gets reported in the meantime.