Proposal: simplify elder.config.js

[jbmoelker]

The current elder.config.js exposes a lot of internals, like locations.svelte.ssrComponents and locations.intersectionObserverPoly. Would it be an idea to reduce the surface that's exposed, simplify the API and make it more common to other frameworks like Next.js and NuxtJS?

current elder.config.js:

module.exports = {
  server: {
    prefix: '',
  },
  build: {},
  locations: {
    assets: './public/dist/static/',
    public: './public/',
    svelte: {
      ssrComponents: './___ELDER___/compiled/',
      clientComponents: './public/dist/svelte/',
    },
    systemJs: '/dist/static/s.min.js',
    intersectionObserverPoly: '/dist/static/intersection-observer.js',
  },
  debug: {},
  hooks: {},
  plugins: {},
};

proposal elder.config.js:

module.exports = {
  target: 'static',                   // default, other values could be 'server' and later maybe 'serverless'
  rootDir: process.cwd(),    // default
  srcDir:  'src/',                     // default, relative to rootDir
  distDir: 'dist/',                    // default, relative to rootDir, was 'public/'
  server: {
    prefix: '',
  },
  build: {},
  debug: {},
  hooks: {},
  plugins: {},
};

• target convention: Next.js and NuxtJS. This would replace the context: 'server' used elsewhere.
• rootDir convention: NuxtJS
• srcDir convention: NuxtJS
• distDir convention: Next.js and NuxtJS

[nickreese]

@jbmoelker I like the idea of simplifying the config. I was never a fan of locations, reworking config was on my notepad to tackle.

Thoughts:

• target: Should this be in the config? I ask because passing it into the new Elder initialization gives us flexibility without having to muck with config files. We can have a server for previewing, build process, and even a serverless process all just by changing the input into new Elder.
• I've recently added siteUrl (added in v0.1.0 yesterday) To be able to build fully qualified URLs.

I'm happy to review a PR on this (and #28) if you guys are hacking on it.

[nickreese]

@jbmoelker All of this is configured aside from the target as it doesn't really work with how Elder.js is currently being used.

#35

Going to be migrating several plugins and our sites to this version of Elder.js then will likely release v1.