I love PL and the work that Dave and Brad have been doing. This is just random bullshit I've been thinking after a week of Pattern Lab use. Just
I've found that working on my current Pattern Lab, the only directory I really need is the source
directory. That makes me think that all the config|core|extras|etc
folders could not exist or be hidden from the user. That way a generic Node process that could be used by grunt, gulp, broccoli, etc might be beneficial. The "engine" is hidden from the user. Then updates could be seamlessly injected where now it'd be a bit of a manual process.
I think the simplicity of just having the files you're working on decoupled from the technology would be great for onboarding new users. Edit your source
files (now at the project root) and point a nodeapp/grunt/gulp task at it.
It feels like a question of do you want it to be WordPress for patterns (engine coupled) or a Jekyll for patterns (engine decoupled/hidden).
Relevant links:
I've wondered if it's easier to just update some JSON instead of keeping folder and file names numerically prefixed. If you delete a pattern, it's a bit of work to re-ordinate all the other files (lots of git changes, etc).
This would maybe help in up-cycling patterns into a larger system (which is a lot of people's dream). I can then tell a backend developer to include()
the molecules/global/pagination.mustache
instead of molecules/02-global/03-pagination.mustache/
, where the numbers seem subject to change. PL could then start existing within a directory of a larger system.
I talked with Brad about this, I know it's on the roadmap. I wonder if Jekyll's _plugins
structure might be good here, and those are little web components (HTML/CSS/JS ... Polymer?) that inject features in to the style guide header. Extensions could be included/excluded using YAML/JSON as well.
IMHO PL is the patterns, not a build system (or shouldn't be), when there are much better existing alternatives that can accomplish what you need. So if the goal is to help PL become a better build system, I'm happy to give feedback if it's desired. But there probably isn't much more I can offer.
Every single thing that has been listed on this gist can be done by Assemble out of the box. Just as PL is about the patterns, Assemble is focused on being able to build components into any pattern you need. If you want to build PL with Assemble, just use the PL helpers. If you want to build YUI docs, use a YUI plugin, if you want to build OOCSS, use a plugin, and so on.
Shifting gears, on the topic of deps, IMO keeping dependencies to a minimum isn't a goal unto itself, it needs to be balanced with what needs to be accomplished. Just as developer convenience is more important than micro-performance, shaving off a couple of dependencies at the cost of losing access to context in deeply nested components would be a bad trade-off. I guess my point is that deps shouldn't even be a part of this discussion. Not until the goal is reached, then we can look for ways to optimize. just my 2c