Adds Browsersync and scripts

[coreymcollins]

Closes #568 #583

I believe this will also close #586 which was initially started by @aubreypwd. Adding him as a reviewer as well to check this out.

DESCRIPTION

Adds Browsersync and adjusts our npm scripts to utilize it. If we decide to venture in another direction rather than Browsersync, that's totally fine but this was a part of our previous workflow and was a fairly streamlined addition (so far).

As noted in the task linked above, there isn't any live reload/Browsersync integration. This adds Browsersync back in and:

• Adds a second npm script called start:sync. If you don't want to use Browsersync, just run npm run start; if you want to use Browsersync, run npm run start:sync
• This listens for changes in the /build/ directory rather than listening for changes in the /src/ directory. As I've found in my testing so far, this makes for a much quicker reload in the browser. I'm not necessarily sure why one is faster than the other since everything still needs to compile, but it seems to work! Maybe because we're listening for fewer files and directories? ¯\_(ツ)_/¯
• This listens for changes in our PHP files so any change you make in a PHP file will reload your local

What this does NOT do yet:

• If you add a Tailwind class in the markup, the browser reloads but the new Tailwind styles are not added. So, if you add bg-blue-600 to the header, you'll get a browser reload and you'll see the class in the markup but the Tailwind styles aren't compiled. These styles only get compiled on build right now, and I'd love to have a way to get them to compile on start:sync without too much of a lag in reloading the browser
• Listen for changes in the src/images/icons directory and copy new files to the build directory or generate the sprite.svg file

OTHER

• Is this issue accessible? (Section 508/WCAG 2.0AA)
• Does this issue pass all the linting? (PHPCS, ESLint, SassLint)
• Does this pass CBT?

STEPS TO VERIFY

1. Check out the branch
2. Run npm i
3. Run npm run start:sync
4. Save a change in a PHP file
5. Add an image to the src/images/ directory
6. Save a change in a Sass partial and JS file

DOCUMENTATION

Will this pull request require updating the wd_s wiki?

Yes, this will require some updates if we decide to merge it in.

[coreymcollins]

Some afternoon updates:

SVGs

SVG copy and sprite.png creation on change of icons is in!

This took adding a second pattern to the Copy Webpack Plugin in our Webpack config file. Now, when you're running npm run start or npm run start:sync and add an SVG file, it gets copied from src to build.

Next, I added the onchange plugin and added a script to watch for changes in the src/images/icons/ directory. When a change occurs, theme:icons is run so (in addition to Webpack copying the new SVG file) sprite.svg is generated.

This all occurs without creating a lot of overhead like we were seeing in #586 (cc @aubreypwd). Saving a Sass partial still takes < 4 seconds as we're not forcing everything to rebuild on file change.

Other notes

Browsersync still runs when saving a PHP file and is generally quick.

As noted above, saving a Sass partial doesn't take any longer than it currently does.

All in all, so far we're adding two packages:

• Browsersync
• onchange

Again, we can discuss whether or not we want to explore using other packages or move any of this to the WDS npm-scripts package, if possible.

Next Steps

I really want to be able to generate Tailwind styles if you add a Tailwind class to the markup somewhere without making Browsersync take a hundred years. Going to mess around with onchange and see how we can possibly build things quickly when PHP file changes happen.

[coreymcollins]

I think I don't want this to get too hung up, and I feel like hammering on the remaining Tailwind item could do that.

I'm going to take this out of draft and send it over for review – and then we can iterate on our Tailwind workflow as we go.

[gregrickaby]

Tested locally, and this works great. Thanks @coreymcollins!