Skip to content

Instantly share code, notes, and snippets.

@dmolsen
Created July 14, 2014 20:41
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dmolsen/b65ee2045a2b70fbc185 to your computer and use it in GitHub Desktop.
Save dmolsen/b65ee2045a2b70fbc185 to your computer and use it in GitHub Desktop.
creating bower packages with pattern lab

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:

  1. Delete all files under public/styles
  2. Commit the deletion
  3. Add public/styles to .gitignore
  4. Create a new repo just for your production styles
  5. Clone the new repo into public/styles
  6. Run a build of your CSS so new files end up in public/styles
  7. Run bower init to create the package
  8. Commit and push the changes to your repo
  9. 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."

Pros

  1. Can control and version new editions with tags
  2. Easy to add to new projects
  3. Easy to update

Cons

  1. Set-up
  2. Version control can be fragmented depending on what you track and where
  3. Node/Bower is a dependency (of course, if you're using grunt/gulp this should be a non-issue)
  4. Removing entry in .gitignore could be messy. Better/cleaner to add as a submodule?

Anything I'm missing?

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.

@RainbowArray
Copy link

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.

@dmolsen
Copy link
Author

dmolsen commented Jul 15, 2014

@mdrummond-

I still don't think public/ should be tracked in a repo. Frankly, I think the workflow outlined above is a perfect use-case of taking those "production" styles generated by Grunt/Gulp from files in source/ and use them in a staging and production instance without needing to include PL itself in the project. Simply commit the generated styles when you're happy and run bower update <package-name on your staging and production instances. But this assumes that you only need styles, JS, or images out of PL and not patterns/mark-up. The crux of the problem, as always, seems to be how to re-use the mark-up and Bower probably wouldn't work well for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment