insin / nwb

A toolkit for React, Preact, Inferno & vanilla JS apps, React libraries and other npm modules for the web, with no configuration (until you need it)
Other
5.57k stars 331 forks source link

Convert to plugin-based architecture #250

Open insin opened 7 years ago

insin commented 7 years ago

Support for all current project types is currently baked into nwb.

Scenario: I want to add support for Mithril.js - currently, to do this I have to:

There is also a lot of duplication in these areas as I'm wary of DRYing things up too early, having already removed some previous DRY modules around creating server configs which made things much harder to follow for the sake of not duplicating 4 lines in a few different places.

The following project types are broadly the same (apps with a Webpack dev serving config and production build config):

As are the following (npm modules with Babel build config and Webpack UMD build config):

To turn these into plugins, we need to determine which bits differ and how we're going to provide them via plugin modules, and which bits nwb can handle the base for to avoid duplicating stuff in plugin modules (altough just copying current duplicated stuff over might be the fastest way to get an initial working version).

The current implementation of style preprocessor plugins is a very simple example of a style I'd like to be able to follow if possible - instead of handing the plugin module everything, the plugin module just gives nwb what it needs to implement a feature - unique ids, paths to dependencies and other necessary config:

module.exports = {
  cssPreprocessors: {
    sass: {
      test: /\.s[ac]ss$/,
      loader: require.resolve('sass-loader')
    }
  }
}

Is there a similar desciptor which can be devised for apps and npm modules?

loklaan commented 7 years ago

It'd be great to move towards a plugin arch for reducing dependencies one might need to run their own nwb instance. :+1: :sparkles:

Something that I see might help you manage the growth in plugins / similar code is to put nwb and all the plugins under a single repo and use a tool like lerna to manage the inter-dependencies / publishing. I don't know if you've done this with any other projects before, but from experience it's very liberating to suddenly only have to deal with a single repo in an otherwise well modularised codebase. I can help more on this if you're interested.

loklaan commented 7 years ago

Example of the project restructured to monorepo, managed with lerna. Not many changes, since tooling is only really needed for the nwb cli so far and not the plugins which are just configs. If that changes, then the linting and transpile tools would need to be lifted into the root of the project.

https://github.com/loklaan/nwb/tree/monorepo-refactor

Don't mind if you reject the suggestion - it's unsolicited after all.

dlmr commented 7 years ago

Hi! 👋

I'm one of the developers behind a project that shares some similar ideas and ambitions as nwb, https://github.com/rocjs/roc, and it has been designed from the ground up as a plugin based system, focusing on solving this type of problem.

Now I'm not exactly sure what you are looking for in terms of API or functionality but a possible option would be to use Roc as the underlaying foundation to make this type of architecture possible in an easy way, that is the core of Roc (you would not need to use the entire existing ecosystem). Roc provides a way to add/modify cli commands, add/modify settings, shared dependencies, integration points in terms of an event system and much more. I would be happy to help in adopting it if this sounds interesting, and if you decided to go another route it might be some useful lessons and ideas to share here.