Monorepo plugins

[loklaan]

This PR tracks the progress of moving nwb and it's plugins into a monorepo, as well as implementing related issues.

Progresses #250, but doesn't resolve it.

• Bootstrap monorepo structure with lerna
• Move nwb into a package in monorepo
• Fix CI concerns. eg TravisCI / Appveyor
• Move existing plugins into monorepo:
  • nwb-less
  • nwb-sass
  • nwb-stylus
• Extract Karma test runner into a plugin
  • Plugin architecture needs to be redesigned to be dynamic
  • A number of pure utility functions needs to be pulled into a seperate package, to share with plugins. eg createWebpackConfig
  • Test (likely need to integration tests from in the plugin)
• Add plugin with Jest test runner Add Jest support #173
  • Validate that the plugin arch works well for Jest too
• Update existing plugins with new plugin architecture, if applicable
• Try to make CI errors easier to read (lerna seems to obfuscate test errors, but perhaps too early to make that statement)

Plugin Architecture

Going forward, plugins are going to fit more cases:

• Provide nwb configs. eg existing plugins
• Projects with build, serve, and other commands. eg react-app, web-module, vuejs...
• One-off commands that use the final nwb configuration. eg Karma/Jest runners, using nwb configs
• Targeted partial templates. eg Templates for Karma/Jest tests

Plugin API Proposal

Exporting an object of a nwb config should still be supported.

To support the other cases, a plugin package could also export a function:

// Plugins can register configuration as a:
//
// * Project
//    register.project
//
// * CLI Command
//    register.cliCommand
//
// * Targeted template
//    register.targetedTemplate

module.exports = function (register) {

  register.project({
    name: 'vue',
    description: 'VueJS app',
    template: '../project-template',
    commands: {
      // Special commands are given webpack helpers to call
      build: function (cliArgs, build) {
        // Create a partial nwb config
        build(nwbConfig)
      },
      serve: function (cliArgs, serve) {
        // Create a partial nwb config
        serve(nwbConfig)
      },

      // Other commands have API like register.cliCommand
      clean: { /* ... */ }
    }
  })

  register.cliCommand({
    name: 'test',
    args: [
      // Example only
      //[ 'entry', 'entry point', 'src/index.js' ]
    ],
    opts: [
      [ 'coverage', 'create a code coverage report' ]
    ],
    callback: function (cliArgs, nwbConfig, doneCb) {
      // doneCb must be called to exit cleanly
    }
  })

  // Project templates can contain files with a type as the name. It will be
  // replaced by the directory/file at './template'
  register.targetedTemplate({
    target: register.testTemplate.TYPES.TEST_AT_ROOT,
    template: './template'
  })

}

A lot of the nwb help, for projects and one-off cli commands, can be inferred from properties of this api.

Note that the build/serve commands for a project aren't provided a nwb config; none of the existing projects need one before given their partial config to webpackServe or webpackBuild, so it was left out of the api.

[loklaan]

Dug deeper into the requirements of the dynamic side of a nwb plugin arch. I've updated the PR summary to reflect the requirements, namely the api proposal code example.

@insin Could I get some feedback if you got some time? I've gathered that you had some ideas about the API from before. It may be a bit involved to give help, sorry, but it'd be goooood before I jump into implementing 💥

[insin]

Monorepo looks 👌

How painful will it be to call a halt to development at some point to get it rebased against master?

I've avoided plugin abstractions so far because you don't know if you've messed up until you've really dug into implementation. Will have some time tomorrow to have a proper look.

[loklaan]

No I get that - early optimisation.

It wouldn't be so bad, but it'd likely be cleaner to replay my steps from the beginning with newest master.

1. Move package into subdir packages/nwb
2. Copy the root dir's package.json and lerna.json from this PR, because they have already tackled CI problems afair
3. Use lerna to import git histories of the styling plugins
4. ...I think that's all the steps.

[insin]

Moving towards being able to register commands in next instead of just using module names in the filesystem.

The build-${type}[-app].js and serve-${type}[-app].js commands are now just calling the same functions and passing a different config module in.

[loklaan]

I'm jumping off of this issue. I'll leave it to insin to close, since it might be valuable for posterity.