#How can we get control over how the output is bundled?

14 messages · Page 1 of 1 (latest)

grizzled apex
#

Hey all,

The bundles that are generated for my project end up being pretty nasty. The CSS isn't being combined together in a sensible way, and each route is generating tiny js imports that would be better off being part of the primary bundle.

I've tried configuring rollup, but it crashes.. I'm guessing start is injecting something that rollup doesn't understand...?

grizzled apex
#

Just an update.. I've mostly got this resolved, though I'm still a little confused by it.

It sems that there's something that causes rollup to crash if manualChunks is used to name some specific chunk. I've no idea what it is, other than it's something that's in node_modules.

For example, this configuration works:

manualChunks(id) {

    if (id.includes('foo')) { // foo is a package in node_modules
        return 'foo';
    }
    
    if (id.includes('bar')) { // so is bar
        return 'bar;
    }
    
    if (id.includes('node_modules')) { //this is necessary to stop rollup from crashing, odd!
        return null;
    }
    
    return 'bundle'; // all app code goes in bundle
}

Without that null return, rollup crashes. Very odd!

eternal root
grizzled apex
#

Thanks, yea I saw that, though it doesn't seem to apply to start...? Or at least, I couldn't get it to have any effect. I tried both adding the vite plugin with the configuration as per that page you linked, and adding the configuration under the router key of the start plugin. Netiher seemed to have any effect.

eternal root
#

it does apply to start . codesplittingOptions is there

grizzled apex
#

I think perhaps it only has an affect on the per-route bundling, not anything outside of that, in that case. Configuring it still resulted in there being a bunch of sub 1kb CSS/JS files, which is fairly undesirable.

Configuring manualChunks via rollup helps, though it seems a bit touchy to avoid having a circular dependency (eg. a chunk that depends on itself, so fails). I'm not entirely sure why - I haven't run into this historically

eternal root
#

full repro?

#

why don't you want the per route code splitting btw? what's the problem here?

grizzled apex
#

I can't share a full repo as that's against company policies, but I can give some background.

The App is an existing SPA that we're migrating to Start, so we know what the historic bundle sizes are/were.

Historically we only had a couple of chunks:

  1. The main UI library the App uses (the UI library doesn't support tree shaking, and is used by every route).
  2. A couple of one-off large components that aren't widely used, loaded with React.lazy
  3. The main App bundle itself, including all routes. Most routes are relatively small as there is a lot of shared code, and the App leans heavily on the UI library from #1

The reason for not wanting per-route code splitting is that it just doesn't serve a useful purpose - there's not really much code to split! The UI library needs to be in a single chunk, and most of the application code is used by most routes.

The downside of code splitting is that it makes the UX a lot worse, as with a cold cache there's a noticeable delay while navigating to new routes, which don't have loaders, as the route js needs to be loaded first, even though 99% of the code required for the route (eg. the UI library, localization, API framework, etc..) is already availablein the client cache

eternal root
#

Doesnt the preload on however eliminate actually noticeable delays?

#

aside from that, what happens if you change codeSplittingOptions?

#

if that doesn't work for you then please create a minimal reproducer based on one of the existing start examples

grizzled apex
#

Sorry for the delay, I have been traveling and dealing with sick children.

Preload on hover is mostly not applicable in this case, as the navigation is initiated outside of the window we control. Our code runs within an iframe, and receives navigation messages via postMessage.

Even if this weren't the case, I suspect it would still be clunky - we have a number of users who are on relatively high latency connections, so a few round trips for various chunks could add up to seconds worth of additional click -> navigation latency.

I'll do some digging around and see what I can come up with - though personally I think more control should probably be provided via say.. createFileRoute to opt-out (or perhaps opt-in) to code splitting for each route, as there are almost certainly a number of places in many pieces of software where combining routes and their dependencies together makes more sense

eternal root
#

you have the control via codesplittingOptions per route