discussion: modular for libs

[threepointone]

parent issue for using modular to build libraries.

[threepointone]

modular was designed for applications, but honestly it seems like a good fit for building multi-package libraries too. Some concerns:

• it's a factor in renaming widgets -> modules rename "app"/"widgets" ? #39 However...
• if modules aren't necessarily react components now, what will the widgets map look like? While generating the widget map won't really 'break' anything, anyone enumerating the keys of the widget map to get a list of available widgets will be mistaken. Which means we either need an opt-in metadata for widget folders/modules, or an opt-out metadata for those that aren't. (so, conceptually widget:true in widget package.jsons, or widget:false in non-widget ones. or, a widgets: [...names] field in the root package.json)
• we could try to be fancy like nx/etc and try to only publish updates to changed files, but in practice that just leads to a mad cluster in package.json of differing version numbers. Instead, let's just do it like React and update all package versions together.
• shared/* shouldn't be used for libs (else, it'll have to be published too). But now that modules/* doesn't have to be just components, devs can just make a module called 'shared' (and remember to scope it).

So what would it look like? I propose no new configuration, and two commands -

• modular lib build: creates a dist/ folder, and built versions of each package under modules
• modular lib publish: publishes the built modules.

I'll go ahead with this once we take a call on how to identify widgets/non-widgets.

[threepointone]

Tracking this work in #253