Split module into `main` and `core`

We could split the bundle into a core module and the normal main one.

We can structure the library so that main, native and no-parser use core, so that the no-parser module doesn’t conflict with main and people can use both alongside each other.

~Furthermore we can make main have the domElements and support styled.div, while the styled export on core could only support styled('div'). This way people can decide to make a really tiny bundle, if they need to.~

This would also solve the problem that libraries might not use no-parser and the user does, or vice versa.

/cc @mxstbr @geelen

[geelen]

Hmm, I don’t mind breaking things apart and I certainly like smaller bundles, but I’d like to keep things grounded a bit. Splitting things in half where there’s a natural division (like core/main) is good, and if that results in a smaller bundle then great, but I don’t think we should be prioritising bundle size over DX, performance, or maintenance complexity. 11kb is fine for a lot of cases, the no-parser one will be even better, and anywhere we can improve weight without compromising the others then go for it. But just keep an eye on the broader goals of the project as you look for opportunities to split things up/slim things down.

That said, core vs main sounds like a good split. I definitely wouldn’t do the styled("div") thing though, but hoisting styled.div into import { div } from 'styled/elements' could make sense (and will be important for my current whitelisting stuff)

[kitten]

@geelen in that case let’s do an elements file first, which should be simple, and a main/core with the goal of no-parser interoperability.

Sounds good? 😃