Customising the styleguide CSS

[1stevengrant]

Am I right in saying that to customise the CSS/markup that Pattern Lab produces, I'd need to be running the dev version?

I'm not talking about my own patterns but rather the PL wrapper.

[bradfrost]

@stevieg83 You can customize Pattern Lab's UI by forking this: https://github.com/pattern-lab/styleguidekit-assets-default and adjusting the styles and markup there.

[1stevengrant]

hey @bradfrost thanks - I'm trying to get my head around how the main repo would bring in any customisations from this fork if I went down that route given that it seems to be an initial composer dependency?

[bradfrost]

@stevieg83 I'm not the best person to answer this, but I can point you in this direction: http://patternlab.io/docs/advanced-ecosystem-overview.html

@bmuenzenmeyer or @dmolsen would be able to speak to how to actually go about creating the environment so that it's all set up properly.

[bmuenzenmeyer]

I cannot speak too intelligently for the workflow of the PHP version, but I'd imagine composer can supply a different copy of styleguidekit-assets-default for you, both during development and in production

For PL Node, during development I would use npm link to point to a local copy of a repository instead of the actual package, and then once happy I either publish it for consumption on the npm registry, or in the case of slightly less-public options, direct from github via orgname/reponame Pretty certain that works for composer too.

Hope this helps.

[jdagerot]

I'm just in the middle of this myself. If find it a bit time consuming to both build the (cloned and modified) styleguidekit-assets-default and my final code, to see what happened.

What's the pitfalls of just changing the /styleguidekit-assets-default/dist/ directly?

(I'm running the node.js version, I know this thread is about the but couldn't find a better thread to ask this in)

[bmuenzenmeyer]

You could certainly do whatever you like with that repo - all that ultimately matters is there there are files in dist/ that function the same way they do now. So, go ahead and unminify them, change them, whichever, but doing so is ceding the build process that comes standard with the repo, let alone future updates.

I feel like this is the natural way of things with the ecosystem - teams will outgrow the default and look to build their own frontend. This was Dave's vision, I believe.