[629] Break nuxt.js up into modules

Why?

Currently, the scope of the monolithic nuxt.js package is already too big and is already growing. Consider the following use cases:

• large scale application (eg social network)
• statically served mostly-offline webapp (firebase)
• electron/cordova app
• Weex app

There's a number of aspects of nuxt each of these won't use. With growing functionality, nuxt will be harder and harder to pick up. Seeing the Issues that get accepted, it is clear the project is moving from "one specific way to make vue ssr applications" to "the best way to develop vue-centric js apps from scratch in most conditions". It's time the project's structure reflects that.

Imo, this will enable easier continued development and use.

What do?!

I am making a far fetched suggestion that I believe will grant this project easier adoption if implemented before 1.0. It comes in two parts:

1. Don't indirect things more than necessary.

• Let the user instantiate their own vue-router or even use a different router, just pass them the output of the pages-file-api feature to give it.
• Leave the webpack configs in the hands of the user. Just giving them an export they can put in their own configs will still allow you to update nuxt version in place, but you won't be reinventing the bicycle by providing apis to override your hidden webpack config.
• Don't deviate from the norm until necessary (.nuxt-link-active, <nuxt-link> that just returns a <router-link> for now.) That's scope and lines of code for nothing.
• vue-meta plugin's metaInfo component property is renamed to head. This (afaik) provides no benefit, unlinks it from vue-meta documentation, and makes it unclear that htmlAttrs and bodyAttrs can still be used.

You have a great ally in vue-cli. Just use that to keep things like vuex, vue-router, vue-loader and webpack (maybe even vue?) in the user repo, and provide a recipe that sets them up out of the box. Small helpers like plugins: [{injectAs}] and setting up aliases for webpack can go in the recipe.

2. Extract parts of nuxt.js as separate modules

For example:

• nuxt-dev: The only one that has watchers/hmr/bundle-analysis/friendly-errors; Tools for developing nuxt applications (as radically opposed to developing nuxt)
• nuxt-build: For building the application for nuxt-serve; Minifiers can go here too.
• nuxt-(serve|start): Serves a built application as a standalone server or programmatically
• nuxt-generate: For generating static site structure.
• nuxt(-plugin?)-offline: The upcoming service-worker/appcache feature

The way I see these, the first 4 should not depend on each other, but should obviously have some common nuxt dependencies.

Could be even more granular; For example, file apis can be extracted.