#patternlab

Patternlab 1.6 was just released on github. This version has basic lineage support, found breakpoints in css added to ish-controls, and more unit tests!

Just pushed patternlab-node 1.2, check out the release here

Here is the changelog:

ADD: Abstracted template rendering into a function for easier swapping of rendering engine

ADD: Smarter filtering of files to support other templates Thanks

ADD: Help command line agument

ADD: Version command line argument

ADD: Patterns only command line argument

ADD: IshControlsVisible options. Can now hide any ishControls you like.

ADD: Documented the command line interface

CHG: Put debug flag in conf.json instead of package.json

CHG: Aligned styleguide css with patternlab-php

FIX: Removed node .8 from travis

FIX: Code and annotation support in patternlab viewer

THX: thanks @ivanmayes and Shoptology crew for contibutions!

More change coming

Interest in patternlab-node is steadily increasing, as as such it needs to mature out of its brute-force port mentality. A notable watcher, Addy Osmani says on his blog:

First do it, then do it right, then do it better. This is one fundamental I always keep in mind when developing anything.

I've just published Pattern Lab Node 1.1 to Github. It comes at the onset of a journey toward adherence to the pattern lab specification created by @dmolsen

Changelog

This release cleans up some messy dependencies, and really sets the stage for more meaningful development.

FIX: Removed View All Pattern SubItem Link Logic, no longer in reference implementation

ADD: Flag for generating debug file

ADD: Travis CI test support!

ADD: Contributing file

ADD: Repository to package.json

FIX: Manage Mustache dependency using NPM

THX: thank you @tbranyen for tip on repository, Mustache, and NPM!

Toward a More Perfect Pattern Lab Node

Stay tuned for version 1.2, already under development in the dev branch! With that version comes a moderate refactor of the builder, more unit tests, and some specification-mandated features. I also hope to get lineage and annotations functional - these have been gaps for too long.

Dave Rupert sparked a conversation today about Patternlab after some initial usage, which elicited a nice round of feedback from others.

Brad Frost summed it up nicely:

It's been a process to make Pattern Lab simultaneously flexible and robust

I want to put some thoughts to paper about how this process has played out for me.

Patternlab-PHP was rather feature-rich when I started. I likely missed the conversations Brad and Dave had about what PL should and shouldn't be. It was simultaneously an amazing living reference, but also a skyscraper to understand, deconstruct and finally rebuild with different materials. Dave Olsen helped immensely in those first steps.

I can feel the desire to turn PL into more than it already is, to turn it into a platform through which an entire project can grow, mature, and finally be deployed. I have also experienced first-hand the complexity that can creep into the solution when attempting to support so many features.

To me, Pattern Lab is:

A tool to build reusable, scalable markup and css snippets. As Brad intended, you can decouple atomic design principles altogether if you so choose, but it's also...

A tool to glue components together in an iterative, incremental fashion.

One of many ways a web project could be built, but not the only way. A multi-tool, but not the best for every job.

An alternative to photoshop comps and high-fidelity mockups as an acceptable design deliverable

So, as I reread this, and wonder at which features to implement next against the living spec that is the PHP version, I question what feels missing to me. (Also excited at the prospect of Dave and Brad writing a spec!)

What pain points have I experienced?

Initial project setup is cumbersome. Hopefully some npm, grunt, dependency maturity in the near-term will help. As others have stated, attempting to obfuscate patternlab internals should be a goal. Addy Osmani suggested a pure node implementation which would be most agnostic. To me, grunt feels more consumable than pure node. I need to look into Assemble.

The iframe-viewer still gets me sometimes. Living in this responsive age, I naturally try to resize my window instead of using the controls. I'v felt at times that the ish controls are not perfect, but haven't been able to determine if it's my problem or something in the implementation yet. I wonder if this can be configurable.

The port is inelegant and immature. I brute-forced the processing of templates, instead of globbing as the PHP version did initially. While I think this is straight-forward and decently documented, it is not DRY or unit-testable. A refactor would do some good.