@caxy/developers I added a whole bunch of tasks on this PR that I need help with if anyone has bandwidth. Otherwise I'll be working through these items the rest of the week slowly.

@jschroed91 I'm unclear on what the added value is of having essentially one file in a repo (caxy-styleguide-webpack-plugin) vs. having that be an 'extra' part of the styleguide branch of the starter kit. Is that repo just incomplete at this point/am I missing a bit of context that would illustrate the benefits of this approach more clearly?

@beckkramer RE: the separate repo for caxy-styleguide-webpack-plugin - there are couple reasons I thought going that route would be beneficial to us and worth the added effort of maintaining the separate package/repo.

1. Open source - there appears to be a need for a more advanced webpack plugin for the kss-node library as was somewhat evident in this thread: webpack plugin kss-node/kss-node#311. The kss-webpack-plugin works quite well for rebuilding the styleguide each time webpack bundles are recompiled, but it doesn't anything beyond that.
   The caxy-styleguide-webpack-plugin goes further and injects the webpack assets into the kss-node configuration so that the styleguide is built with the application assets included - which is quite valuable.
   It still needs quite a bit of work on documentation and some work in the code itself ... but the ultimate goal is to have a full-featured kss webpack plugin to share w/ the community

2. Since this is a starter kit, all of the projects that are cloned from this kit will likely not be getting regular updates from the upstream starter kit as it evolves - so most projects won't be getting the updates made to the starter kit as it evolves, and it might be a difficult process to merge the updates from upstream into the project if there were customizations made to the boilerplate code (which is likely).
   So ... de-coupling some of the smaller things like this webpack plugin will actually allow those projects to get updates to these separate packages easily without having to go through a merge-conflict nightmare trying to merge upstream into the project - they can simply run yarn upgrade caxy-styleguide-webpack-plugin to get the latest version and take advantage of any new features

Makes perfect sense, thanks for breaking that down.

so as an outsider looking in here.....

I have been trying to use the kss-webpack-plugin, but i noticed that the styleguide doesn't actually render the styles when running a watch (only when running a build) because the css needed is an actual static file. Should i be using this new plugin instead?

@mephilip That's a great question - we actually discussed that same issue today for the webpack plugin we wrote for this: https://github.com/caxy/styleguide-webpack-plugin

You can try that plugin out for yourself to see if the remedies the issue - the plugin is very similar to the kss-webpack-plugin, but it takes it a little further and injects the assets that were compiled by webpack into the kss-node configuration. Not sure if that will solve your exact issue or not.

There's one limitation w/ the plugin that we plan to update in the coming days - right now it only rebuilds the styleguide when webpack recompiles any assets, but if you're passing any assets into kss-node that aren't actually compiled/watched by webpack, then it won't rebuild (pattern markup partials for example).

@mephilip Also - forgot to mention ... our webpack plugin isn't documented at all at this point - but if you wanted to try it out, you could have a look in this PR for an example of how to use it
https://github.com/caxy/front-end-starter-kit/pull/17/files#diff-a58d55bdb5770c78ad512f8e91f8d051R71

I am actually working on the documentation right now!