Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert to plugin-based architecture #250

Open
insin opened this issue Jan 30, 2017 · 3 comments
Open

Convert to plugin-based architecture #250

insin opened this issue Jan 30, 2017 · 3 comments

Comments

@insin
Copy link
Owner

insin commented Jan 30, 2017

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:

  • register a new app type constant
  • create a new src/bin/ script to support mithril run and mithril build (practically duplicating the preact and inferno scripts)
  • create a new skeleton project in templates/
  • create a module which provides common server configuration so it can be reused when serving using nwb's dev server and when using Express middleware
  • create mithril-specific serve, build and test commands in src/commands and register them with the generic versions of these commands

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):

  • react-app (unique feature: --preact and --inferno flags)
  • preact-app
  • inferno-app
  • web-app

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

  • react-component (unique features: demo app, propType wrapping/stripping, --no-proptypes flag)
  • web-module

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
Copy link
Collaborator

loklaan commented Mar 9, 2017

It'd be great to move towards a plugin arch for reducing dependencies one might need to run their own nwb instance. 👍 ✨

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
Copy link
Collaborator

loklaan commented Mar 14, 2017

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.

@loklaan loklaan mentioned this issue Apr 4, 2017
10 tasks
@dlmr
Copy link
Contributor

dlmr commented Apr 4, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants