dev branch: Add copy commands for public/styleguide assets

[bmuenzenmeyer]

When changing public root paths, styleguide files do not get copied by anything. add copy commands (short term fix - until #133 lands)

Broken out of #222 to do list item

Remaining work

• filesystem and config changed over
• gruntfile changed over
• gruntfile scss and css testing
• mustache testing
• gulpfile changed over
• gulpfile scss and css testing

[geoffp]

@bmuenzenmeyer -- I have a copy step in gulp that I can contribute, but it works for me because I copy the styleguide assets from inside my my_patternlib/node_modules/patternlab-node/public/styleguide to a target public directory in the host project, like my_patternlib/public/styleguide.

Without that separation, I think this is awkward because we'd sort of be copying public/styleguide onto itself by default, or we'd have to disable the copy step by default. Might this be a good time to pull the styleguide source out of public so that public can start to become a true, clean-able build target that you never edit? This might also pave the way toward using the PL-PHP styleguide UI.

[bmuenzenmeyer]

We're on the same wavelength :)

The issue name is perhaps misleading. Some solution is needed, and I was
hoping to avoid major restructuring... In favor of getting 1.1.0 wrapped
up.

But it might be time. I did start looking at ideal file system last night
and will come up with something akin or like PHP
On Fri, Jan 8, 2016 at 10:49 AM Geoff Pursell notifications@github.com
wrote:

@bmuenzenmeyer https://github.com/bmuenzenmeyer -- I have a copy step
in gulp that I can contribute, but it works for me because I copy the
styleguide assets from inside my
my_patternlib/node_modules/patternlab-node/public/styleguide to a target
public directory in the host project, like my_patternlib/public/styleguide
.

Without that separation, I think this is awkward because we'd sort of be
copying public/styleguide onto itself by default, or we'd have to disable
the copy step by default. Might this be a good time to pull the styleguide
source out of public so that public can start to be become a true,
clean-able build target that you never edit? This might also pave the way
toward using the PL-PHP styleguide UI.

—
Reply to this email directly or view it on GitHub
#229 (comment)
.

[bmuenzenmeyer]

I just ran out of time last night/early this morning to give it proper
thought.
On Fri, Jan 8, 2016 at 10:53 AM Brian Muenzenmeyer <
brian.muenzenmeyer@gmail.com> wrote:

We're on the same wavelength :)

The issue name is perhaps misleading. Some solution is needed, and I was
hoping to avoid major restructuring... In favor of getting 1.1.0 wrapped
up.

But it might be time. I did start looking at ideal file system last night
and will come up with something akin or like PHP
On Fri, Jan 8, 2016 at 10:49 AM Geoff Pursell notifications@github.com
wrote:

@bmuenzenmeyer https://github.com/bmuenzenmeyer -- I have a copy step
in gulp that I can contribute, but it works for me because I copy the
styleguide assets from inside my
my_patternlib/node_modules/patternlab-node/public/styleguide to a target
public directory in the host project, like
my_patternlib/public/styleguide.

Without that separation, I think this is awkward because we'd sort of be
copying public/styleguide onto itself by default, or we'd have to disable
the copy step by default. Might this be a good time to pull the styleguide
source out of public so that public can start to be become a true,
clean-able build target that you never edit? This might also pave the way
toward using the PL-PHP styleguide UI.

—
Reply to this email directly or view it on GitHub
#229 (comment)
.

[geoffp]

Hey -- you're holding up amazingly well under the sudden flood of pull requests. :)

I guess it depends how disruptive moving directories around actually is; I admit I have no idea, except to say that we did all that configurable path and npm-ify work in part to dodge disruptions like that.

Do you think it's better to move just one thing now, and do a larger restructuring for 1.5 or whatever, or just to say that this need has finally forced the issue and do it all at once? Or, I suppose you could just say, hey, configurable paths are here, but changing the styleguide path isn't supported quite yet.

[bmuenzenmeyer]

I'm not sure how to quite answer your question yet. I was hoping pattern engines and configurable paths would land first, but that's all told a bunch of change already. My overriding concern is making upgrades as simple as possible, and in the future, near effortless for users. My guiding light will be getting to a state where users that wish to have all their source outside the pl directory happy, and all users running more standalone only copy/backup the source/directory (and maybe config) without worry of having to manually update files.

All this while trying to orient towards the file structure of PL PHP 2 so we can use some of the assets and starterkits. Nothing impossible, just a lot of balls in the air to keep track of.

For now, getting config patterns shipped seems like a big win, however ugly/temporary the styleguide issue is.

Stay tuned. Thanks for your continued effort and thoughts. I ALWAYS appreciate seeing them. It's crazy clear to me how valuable it is bringing more people to the table!

[bmuenzenmeyer]

UPDATE
I've mapped this work as part of the proposed restructure on the wiki.

This will be the first of the work (to get 1.1.0) out the door.

#133 and #169 will be 1.2.0 most likely

[geoffp]

So then are we doing the proposed filesystem restructure for 1.1.0?

[bmuenzenmeyer]

This issue will likely stub in the ./core directory along with ./core/styleguide/ along with the mechanism to build and copy that over. The other cards on that wiki will be 1.2.0.

My motivation is to get 1.1.0 out sooner, and the impediment being the styleguide being nested in public/ in my opinion,

This work?

[geoffp]

I agree, that sounds good to me. I'd be happy to contribute my gulp styleguide copy task once the directory moves over. FYI, it looks like Target's going to need to build need at least one alternate styleguide/UI sooner rather than later.