Proposal: move Rollup config into Elderjs/elderjs

[jbmoelker]

Currently an Elder project's Rollup config lives entirely inside the project's code using Elderjs/template > rollup.config.js. This means that when Rollup config changes are needed based on a change in Elderjs/elderjs the Rollup config in Elderjs/template needs to be updated in tandem for new projects. And all Elder projects bootstrapped with the template need to adjust their code when updating their Elder version.

So my proposal would be to move the Rollup config into Elderjs/elderjs and make it available in projects. So inside a project's rollup.config.js it would look something like:

const { getRollupConfig } = require('@elderjs/elderjs');
const elderConfig = require('./elder.config');
const svelteConfig = require('./svelte.config');

module.exports = [
  // project's other Rollup configs
  ...getRollupConfig({ elderConfig, svelteConfig }),
];

The result would be that users can still configure the project using elder.config.js and svelte.config.js and extend their own rollup.config.js. But it will be much easier for the Elder team to make changes to its own bundling configuration (#3).

[nickreese]

Rollup

Here are the items that need to be addressed as we move rollup in the core. This relates a lot to the discussion here: #31

Plugin Defined Template Support:

I'd like plugins to be able to define their own templates as this is required to offer basic themes and in many cases plugin specific functionality. That said, I've yet to have time to implement this or test it due to needing to add support for it in the rollup config and there have been higher priorities.

If plugins are offering their own templates, our rollup needs to detect the defined templates, find them in the node_modules or in the plugins folder and bundle them.

This shouldn't be hard, we check the elder.config.js for plugins, check the two folders, and add ssr and browser bundles for any files found.

A Plan for ESM/Systemjs

The actual support for ESM can probably be addressed in the future, but we should decide how these options will be configured and where (probably the elder.config.js).

After investigating this, I think we should plan on offering esm and systemjs side by side that allow browsers that don't support modules to use systemjs.

My biggest concern with this route and internalizing the rollup config in general is that is that while I understand 98% of what is going on in our rollup configs... I'm very weary of personally needing to maintain the integration and user edgecases and scope creep.

I'm hopeful of community support, but fighting rollup is one of my least favorite programming tasks. related: #3

Offering Bundled CSS vs Writing it to the Head:

By default Elder.js emits the css from svelte components onto the cssStack which then gets written to the head but there is a need to support writing all of the CSS to a file that isn't unreasonable.

Currently users can just modify their rollup.config.js and do it themselves, but now we'd be in-charge of adding that functionality.

Doing this would cause even more complexity in the rollup.config.js.

Context:

The current design decision we made before ElderGuide.com used Svelte 100% for templating.

Before using svelte, the predecessor to Elder.js was a hybrid of lit-html esque code and an early version of svelteComponent.ts.

Since the majority of the templating besides the interactive parts were done in lit-html we weren't concerned about the css being in the head.

Now that all of the templates are done in Svelte it is easly to see that there is room for optimization here and users are already requesting it.

[nickreese]

@jbmoelker This is implemented on this PR: #35

May just make this a v1 once I get the elder.config.js changes done.