Split osc.js up into separate micromodules in a monorepo structure

[colinbdclark]

osc.js' monolithic structure is simple for maintenance but has also caused the bulk of support issues over time, particularly due to the fragility of the serial port module.

osc.js should be factored into a monorepo containing at least the following modules:

1. osc-core, which contains only the fully cross-platform, transport-less core (i.e. the current osc.js file
2. osc-web, which contains the transports designed to run in a browser (i.e. osc.WebSocketPort and which provides sufficient Node-style module fiction in order to allow for better support for the use of Browserify and WebPack (by users, not by osc.js itself)
3. osc-node, which will contain the transports that run on Node.js without the need for significant third-party dependencies (with the exception of, I imagine, the ws module)
4. osc-node-serialport, which will contain the osc.SerialPort transport
5. osc-chrome-app, containing the Chrome API transports

[natcl]

Curious to know how monorepo works with NPM. Would it make it possible to get only the core in my project?

[colinbdclark]

Hi @lange, good question. Here are a couple of links that I found helpful:

https://github.com/babel/babel/blob/master/doc/design/monorepo.md
https://gist.github.com/nolanlawson/457cdb309c9ec5b39f0d420266a9faa4
https://github.com/boennemann/alle

There is a tool called Lerna for managing monorepos, which I was originally planning to use for this, but it looks like PouchDB and other libraries have successfully created monorepos without the need for additional tooling.

From a source control perspective, all the modules will be one unit (i.e. stored in one git repository), but from npm's perspective, it will be composed of a series of self-contained modules that can be installed and versioned independently.

It will probably help a little bit with navigating the codebase, though osc.js' is already structured at a physical level (i.e. file structure) in independent layers for Node, browsers, and Chrome apps. The biggest benefit this factoring will give us the ability to not have to deal with the build-time complexity and brittleness of the serialport module in cases (such as yours, I think) where it's not actually used.

I hope this helps!