Move BrowserSync back into core

[bmuenzenmeyer]

Part of #603

[raphaelokon]

I can port the stuff I have in the CLI for serve or the stuff we have in the edition for serving into the core. I guess patternlab node-team need to decide on the serve API here and its responsibilities.

[geoffp]

I suggest that to build arbitrary toolchains from inside any JS tooling, be it Gulp, Grunt, Broccoli, my own app, or whatever, I need to (at least) be able to:

1. Configure Pattern Lab's BrowserSync however I want. I suggest that our current config becomes a defaults object, and the host JS can override this as needed by providing any subset of it.
2. Trigger just BrowserSync's reload() method whenever an event occurs in my toolchain. For instance, if I'm using SCSS + autoprefixer, postcss, or some such thing, I need to set up my own file watches for .scss or .css, and tell BS to refresh my browser views once my CSS pipeline has finished its build.
3. Trigger a pattern rebuild when an event occurs in my toolchain. This would be used for situations in which patterns need to change in response to conditions in the CSS toolchain, such as style inliners for HTML email authoring, or for some of the CSS-in-JS technologies from the React world.
4. Catch events that come from PL in my toolchain. If I want to integrate a JS linter (for React components or other case in which my patterns are JS-based, an HTML linter (for plain template-y patterns), or any other testing tool, my toolchain needs to know when a pattern file has changed so I can run those tests against it. This could be done by PL returning a Node stream that users could use to raise events, but that may not allow the toolchain to halt the build if there's an error. Maybe that's okay. We could also do this without a stream by providing callbacks to PL at init time.

[raphaelokon]

@geoffp Your comment is gold!

[raphaelokon]

1. Sounds fairly easy and I consider this a low-hanging fruit. And yes, a sensible default would be great.
2. & 3. Seems to be stuff related to a specific toolchain. So the toolchain calling PL's API like build or reload
3. Is PL currently built on an event-based architecture?

[geoffp]

Is PL currently built on an event-based architecture?

It is not, but in this hypothetical, I think these events would come from the new file watchers, which are, and would act as the execution root in this case, emitting events to the returned stream and calling PL methods in response to filesystem events.

[raphaelokon]

This is great and is no show stopper for the CLI – one could hook up additional commands to run on certain events from a command-line interface or pipe file paths to do further operations.
As long as the event-based architecture is not build around a certain toolchain/framework it also should be pretty flexible.

[...] my toolchain needs to know when a pattern file has changed so I can run those tests against it
Sounds a bit like a toolchain could figure that out by itself or streaming those paths outworn we have watches integrated into core

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bmuenzenmeyer]

Brian to address #609 (comment) soon.... 🚀