Earlier today @_beneverard tweeted about a common problem with managing style guides. He said:
For those who have created extensive pattern libraries, how do you go about using that CSS in a project? Manually copy it across?
I started thinking about how we could encourage this in Pattern Lab. A lot of my recent work on PL has revolved around creating packages for Composer and it seemed like this was a similar problem. After playing around I'm curious if folks would think the following process was an onerous workflow. Let's say we're going to track our styles and grunt/gulp uses public/styles/
as a target directory:
- Delete all files under
public/styles
- Commit the deletion
- Add
public/styles
to.gitignore
- Create a new repo just for your production styles
- Clone the new repo into
public/styles
- Run a build of your CSS so new files end up in
public/styles
- Run
bower init
to create the package - Commit and push the changes to your repo
- Run
bower register <package-name> <git-endpoint>
to register your package
You can now run bower install <package-name>
in your projects and pull in the CSS you "release."
- Can control and version new editions with tags
- Easy to add to new projects
- Easy to update
- Set-up
- Version control can be fragmented depending on what you track and where
- Node/Bower is a dependency (of course, if you're using grunt/gulp this should be a non-issue)
- Removing entry in
.gitignore
could be messy. Better/cleaner to add as a submodule?
Other than probably using a Git submodule this seems like an OK workflow. The same could be done for other static assets. Patterns remain problematic though with the addition of pattern engines (meaning you can expand beyond Mustache for patterns) I'm hoping those become easier to share too.
Interesting. I'm going the opposite route of using Grunt/Gulp to push compiled production styles into the public folder for use with PatternLab.
I have a repo for my site that I push from my local machine to the dev server (which then moves to staging and then production). Since I keep my pattern lab inside of my site's files for pushing to the server, I'd be reluctant to use a separate repo for public styles, as it gets pretty messy having one repo inside of another repo.
For somebody using a different workflow, this might work great though.