This is an intersting one. I think we probably need to make it configurable if we want to change anything. I think the two requirements I see are:

• Using a CDN is a sensible default - typically it should be faster unless you do hard refreshes.
• Documentation should also work offline.

At the moment you can solve this with a custom theme, however, I can see that isn't ideal. I can't think of another solution at the moment.

I'd probably go with just including it locally. Imperfect but good-enough and doesn't require any extra config, documentation etc...

Ok, lets vendor jQuery :) Unfortunately I think it means we need to include it n times, where n is the number of themes.

Can't you have a build step which copies vendored resources to each theme for each release artefact? That way you avoid duplication of code in the repository.

Yup, good idea - it just adds some complexity. How do we know if a theme needs jquery? What if they use different versions etc.

where n is the number of themes.

I think we should only be including the MkDocs and ReadTheDocs themes. The bootswatch stuff outghta get packaged seperately rly.

Regardless of packaging the themes separately, each theme ought to define their dependencies in a consistent manner. What solution you use for that is up to you, but once you have it, it's easy to track what depends on what and satisfy those dependencies.

I would just avoid any notion of dependancies as much as possible, just include the theme wholesale. It's the simplest possible thing that works.

I appreciate keeping things simple. Despite the fact you already have unmanaged dependencies, I'm sure once it becomes a hassle, you'll pick the right tool for the job.

Updating title with what I think is reasonable upshot of this.

One of the use cases is generating docs for completely isolated environment (i.e. with no internet access at all), so an option to have all resources locally (js, css, fonts, everything) would be really nice.

Yeah, agree that all the resources should be locally available.