Live Reload and dev build times

[gregrickaby]

The Problems

• During active development of client project with wd_s, Live Reload can take 3-6+ seconds to display changes.
• This adds up throughout the day + weeks.
• The root cause is how Tailwind works along with Purge CSS.
• The devs behind Tailwind are working on a solution to this problem.
• There are no editor styles, so our blocks don't look like the frontend.
• Are we expected to write our styles twice? Are engineers supposed to make design decisions when it comes to the admin side of blocks?
• Styling blocks for the editor also takes time and eats into the budget.
• Also, I feel like our NPM scripts are getting a bit out of control. There are so many, which do we run? Why are we calling wds-scripts which is just a wrapper for wordpress-scripts?

Discussion Topics

• Is there anything we can do to decrease incremental dev build times?
• What can we do about editor styles?
• Is there an expectation for engineers to make design decisions?
• Can we simplify our NPM scripts?

[michealengland]

Even though we're likely going a different direction, here is a spike branch that does the following:

Note: Rebuild times appear to range from 3500ms to 4000ms on my local. Which is not much more than before these changes.

1. Abstract Tailwind into a separate webpack entry.
2. Creates style.scss and editor.scss for importing styles
3. Update enqueues similar to Separate Theme & Editor Stylesheets #600 since these updates are very tightly coupled with this update
4. Add @tailwind base; to style.scss and editor.scss so that we can control the behavior behind this feature and address some concerns around selector name scoping.

See spike/mle-abstract-tailwind-imports