Refactor concerns (including build/routes) into Nuxt modules

[weotch]

I think this behavior could be added by a Nuxt module rather than a standalone file. This may fix some of my ESM type issues. Ha or could complicate them ... but it does seem more Nuxt-y.

[weotch]

Maybe all of the concerns and merge boilerplate stuff becomes a Nuxt module...

[weotch]

One advantage of this is that it means that some properties, like extendRoutes, can be added to rather than replaced. I'm thinking that each cloak concern becomes it's own module. You can use all, selectively use some, or duck punch one before using it.

[weotch]

I think I should rewrite them all in vanilla JS because I think this is a nice API:

# nuxt.config.coffee
export default
  buildModules: [
    '@bkwld/cloak/modules/routing'
    '@bkwld/cloak/modules/ssg'
    # ...
  ]

If I have a transpile step, I think they would all have to be in a dist directory. Unless I do like /modules/src/routing that compiles out to it's parent ... but, yeah, eh.

--

I also think the build file generate.routes config should be it's own separate, CMS-specific module. Like @bkwld/cloak/modules/craft-ssg-routes or something like that. And it doestn't depend on an external .gql file. Instead, I think it just blindly fetches all entries that have uris and doesn't grab payloads (since this tie up the DB server on sites that have a lot entries).

[weotch]

Capturing misc implementation notes:

• Make @cloak-app/boilerplate for most of config
  • See Migrate @bkwld/cloak cloak-boilerplate#1
• Make @cloak-app/craft and @cloak-app/contentful for CMS specific stuff
  • This includes making the axios CMS adapters. These will primarily be Nuxt plugins that inject themselvses but they should also export factory functions for use outside of Nuxt. I like factory function because I think there are times where I ran into issues when they are instantiated as a side effect and this way I have a place to pass in project-specific options if I need to.
    • Would be cool to add retrying again to these at some point...
  • These would each have their own, unique page-mixin definitions
    • Sure would be cool to auto-inject these...
• Make @cloak-app/visual
  • I think this should be loaded by boilerplate, but maybe it's loaded by the CMS ones?
    • I think CMS packages should own their own adapters