You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 7, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 7, 2023. It is now read-only.
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?
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.
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)
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.
Activity
bradfrost commentedon Jan 16, 2017
@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 commentedon Jan 16, 2017
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 commentedon Jan 16, 2017
@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 commentedon Jan 16, 2017
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-defaultfor you, both during development and in productionFor PL Node, during development I would use
npm linkto 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 viaorgname/reponamePretty certain that works for composer too.Hope this helps.
jdagerot commentedon Jul 3, 2017
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 commentedon Jul 3, 2017
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.