Runtime: deliver runtime from css-blocks core?

[chriseppstein]

This issue was originally filed by @amiller-gh against the runtime repo which has been merged into the css-blocks monorepo:

It doesn't make much sense to deliver as an independently versioned peer dependency. The rewriters will use a specific version of the runtime and that runtime will most likely be coupled to the version of css-blocks. Instead, css-blocks can:

1. Return to the rewriters the exact arguments that must be passed into the helper, instead of raw boolean expressions.
2. Expose the runtime in a well-defined location for rewriters to proxy up to the app they are integrated into.

This will reduce project module complexity and help to unify implementations of css-blocks across the board.

[chriseppstein]

@amiller-gh Initially, that's how I had it structured (well, it was part of the @css-blocks/jsx module) but webpack kept pulling server-side code into the runtime bundle even though I had configured webpack to use it via the browser property in package.json. Shipping this as a separate module meant that there was less project complexity for the consuming application to ensure that it didn't pick up server side code.

Also, the build configuration for runtime code is completely different than for server side code -- by having this as a separate module, the build steps are uniform across the different packages in the monorepo.

Now that the runtime is part of the monorepo, we'll be able to keep changes in sync across releases without a lot of fuss. does the monorepo change the equation at all for you?

I do like the idea of providing a helper that makes using this runtime library really easy and I think we should definitely expose that in css-blocks core.