Support integrations / alternative build processes

[gadicc]

It's been stated already that this is on the roadmap, but obviously lower priority than critical work on Framework itself. Nevertheless, I thought it would be a good idea to keep an issue open for this, as a central point to be referred back to, and to accumulate ongoing thoughts, requests, etc so we all have a shared, clear vision of where this is headed.

(Framework team -- feel free to edit this first message as you see fit)

Roughly estimated, non-committal target date: October? (can be updated over time)

Tasks:

• Separate Framework into builder, compiler and client parts (see below)

[gadicc]

My biggest suggestion, architecturally, would be to separate Framework into 3 distinct parts and/or npm packages.

• The client-side code for easy inclusion of the parts of Framework that need to be on the client (and integrates with the same require/module systems that Engine does; it should not include Engine code itself, only require a particular version of it).
• The compiler code that processes components and prepares the final version of them to be sent to the client -- with a clear, public-facing API. Ideally this should be streamable (writing of actual output files should be optional), support both sync and async methods (either of which might be a requirement for particular build framework), and perhaps ability to handle single files and return output code + a list of deps; with a "full" build method that depends on this too.
• The builder, which integrates with famous-cli but uses the compiler's public API in what would also serve as a clear model for imitiation by plugins of other build frameworks.

To be clear, I have limited experience with Framework and of course defer to the Framework team and their knowledge of the inner workings of the code. I mention only what makes sense to me as an integrator, with beneficial intent. If the team has their own ideas already of how they'd like to support integrations, they should feel free to edit the 1st post accordingly.

[trusktr]

• a list of deps;

That will be helpful for the Meteor integration.

ability to handle single files

@matthewtoast If the famous cli tool can be specifically be told which files to compile, with dependencies specified on a per-entrypoint/per-component basis, with the cli tool handling Framework dependencies across all of those entrypoints (components), then that would help a lot with Meteor integration because then we'll be able to specify those entry points in Meteor packages and run the famous cli tool during a specific part of a Meteor app build in order to share Framework dependencies across the files (which can be across Meteor packages), so it'd work well with Meteor's upcoming build architecture. Let's talk more in person about this if you'd like!

[faceyspacey]

+1