feat: support theme default config and extra pages rendering

[meteorlxy]

Three features:

1. Support theme default config by theme-dir/config.js
2. Allow custom theme to render extra pages (#198) (Another implementation Feature: theme-related pages #313)
3. Allow user to render extra pages based on a theme (Dynamic routes do not get generated with build #160)

Feature 1 is necessary for Feature 2. I propose to use theme-dir/config.js, which is similar to .vuepress/config.js, as the theme default config

To achieve Feature 2, add extraPages in theme-dir/config.js, and add coresponding extra routes in theme-dir/enhanceApp.js. That will enable extra pages rendering for theme.

To achieve Feature 3, add extraPages in .vuepress/config.js, and add coresponding extra routes in .vuepress/enhanceApp.js. That will enable extra pages rendering based on a theme. Notice that theme's extraPages config could be overwritten in .vuepress/config.js.

E.g:

// .vuepress/config.js
// or theme-dir/config.js
module.exports = {
  extraPages: [
    '/test'
  ],
  // other config...
}

// .vuepress/enhanceApp.js
// or theme-dir/enhanceApp.js
const Test = () => import("./Test");

export default ({ Vue, options, router }) => {
  router.addRoutes([
    { path: "/test", component: Test }
  ])
}

Docs will be added after accepted.

[meteorlxy]

What do you think about this? @mdaffin

[ycmjason]

Just my opinion. It is not something you have to change.

[ycmjason]

Just my honest opinion 😊❤️🙈, I think 335-344 would be cleaner with the following:

if (fs.existsSync(configYmlPath)) {
  return await parseConfig(configYmlPath)
}

if (fs.existsSync(configTomlPath)) {
  return await parseConfig(configTomlPath)
}

if (fs.existsSync(configPath)) {
  return require(configPath)
}

return {}

[meteorlxy]

Uh looks better. I just moved things down into a function without much refactor.

[ycmjason]

Yea yea! Just spot that when I see the changes, might be worth it to make the change.

[ycmjason]

Another note, I see there is a lot in the prepare.js

for (file of ...) {
  await render(file)
}

Is this intentional? Since it looks like this will slow down the prepare process a lot? Or the rendering needs to be done sequentially?

[meteorlxy]

@ycmjason Maybe we should ensure all the files have been rendered? Or some of the pages may not be rendered before the script exits?

[ycmjason]

@meteorlxy
The current implementation make sure one file is rendered after another. I wonder if this is intended. We could have used await Promise.all(promises) instead of for-await. Let me try it on my local and submit a PR regarding this.

[meteorlxy]

@ycmjason Yeah, I also thought about Promise.all but didn't try it 😄

[ycmjason]

@meteorlxy
9719bc3

Looks like the for-await loop is intentional. I wonder why tho.

[ycmjason]

I see, this is probably for better CLI output. The time is not much different so Evan chose to use for-await probably..

[Feofilakt]

Why is it closed?