search

onivim / oni

Oni: Modern Modal Editing - powered by Neovim
https://www.onivim.io
MIT License
11.34k stars 298 forks source link

[RFC] Modularization #2326

Open TalAmuyal opened 6 years ago

TalAmuyal commented 6 years ago

TL;DR

Let's split up Oni into pieces in a way that will make it easy to understand and develop.

Proposal

This proposal has several sections, let's discuss each and get a plan running :)

Layout

(root)
│
├─ api
├─ core (The bare minimal for Oni to work)
│  ├─ Electron/Neovim stuff
│  ├─ PluginManager
│  ├─ ConfigManager
│  └─ ...
├─ plugins
│  ├─ Sidebar
│  ├─ AutoPairs
│  ├─ MarkdownPreview
│  └─ ...
├─ ui (various UI components to be used by core and plugins)
└ ...

The idea is to keep things as flat as possible while giving it some general classification. For instance, using the above example, a user that wishes to add a new plugin and need some examples can immediately find it.

Set UI components as part of the API

Providing the UI as part of the API can help developing more plugins that require GUI with much less hassle thanks to reuse (see example)

Mono-repo

Move in the API

The main advantage is for changes/features that also effect the API or a change to the API that effects (possibly) multiple plugins.

Also, a mono-repo supports publication of multiple packages, so no loss there.

Implementation

Yarn Workspaces might be good for implementing that (though I didn't try it myself).

Even without Yarn Workspaces, this can be achieved using Local Modules.

CrossR commented 6 years ago

This is fairly similar to some of the discussion over in #2022 and has been discussed on Discord a little. I think the one main difference is that we discussed splitting it up as mentioned, and splitting into seperate Git repos.

That fits with how Oni currently is setup (with the API, Logging, Window management etc all being moved out with more being done soon).

I'm a fan of small focused repos since it makes contributing less scary since its a lot lot less files. That said, it can also end up that you end up needing a change in the API and the main repo, so that could potentially get worse if we start splitting up stuff lots, so we should maybe consider what the best plan is for that so repos aren't forgotten about.

If we have good tests for all repos, and potentially add collaborators to the other repos so a user isn't waiting on a single person to merge, I think that would cover it.

But in general, very excited to do this, and it looks like @bryphe has done a bit already by the looks of the new repos over in https://github.com/onivim. I guess the final steps is to split out more and more, and also make sure the installation procdure for the non-core bits is seamless. That way, we can have users install stuff easily, or let the vim master not install tutorials, or the purists not install the sidebar at all etc.