Update build/bundle

[JayPanoz]

As seen in #205 and its comments we are aware we need to rethink build and distribution.

For context, we have been historically relying on Vite to deal with Readium CSS as ?inline – it is now ?raw thanks to the Injection API. And we’ve been using the recommended way of building,libraryMode.

This is an issue for tree-shaking though, as experienced by others but also us in Thorium Web, with the build size not optimised as it should be. This is not unexpected and is actually a known issue.

Insights from @smoores-dev:

Note for discussion: if we want to continue using vite/esbuild for transpilation, but stop bundling, we probably actually want to use .js extensions in our imports, not .ts, because esbuild doesn't support rewriteRelativeImportSpecifiers. If we instead switch to swc, then we can keep the .ts specifiers. Let me know what you're thinking on that front!

Also, on the note of unbundling — I think, in addition to (actually, contributing to) bundle size, there's an issue where the same package can end up included in the bundle multiple times, because each package is bundled separately, first, and dependencies are currently included in the bundle. This can mean that there are multiple instances of the same class definition, which don't get merged, which breaks some things (like instanceof checks).

And from Discord:

Re: unbundling and the raw imports — there is an esbuild raw plugin that handles the same import format that you currently use with vite. You could use this with plain esbuild or tsup to transpile without bundling!

I will give this a deeper look from PR’ing RTL + CJK, as it actually changes how Readium CSS is handled, so it will be a good starting point to handle this. In the meantime, any other feedback and input is greatly appreciated.

[chocolatkey]

Something I ended up doing for previous working involving a much older version of the ts-toolkit was to split the major navigators into lazy imports that the bundler would split up and automatically load as JS files when necessary. It wasn't the perfect solution but it did avoid for example loading code related to fixed layout when loading only a reflowable publication (or, much larger, only loading PDF code when necessary)

[smoores-dev]

That makes sense. I think step one is simply not bundling distribution files, so that bundlers can tree shake out navigators that they don't need. It's possible that other structure and configuration changes will also be needed, but I think distributing unbundled files is the baseline