-
Notifications
You must be signed in to change notification settings - Fork 331
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
Comments
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. |
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. |
Hi! 👋 I'm one of the developers behind a project that shares some similar ideas and ambitions as 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. |
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:
src/bin/
script to supportmithril run
andmithril build
(practically duplicating thepreact
andinferno
scripts)templates/
serve
,build
andtest
commands insrc/commands
and register them with the generic versions of these commandsThe 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:
Is there a similar desciptor which can be devised for apps and npm modules?
The text was updated successfully, but these errors were encountered: