Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dev branch: Add copy commands for public/styleguide assets #229

Closed
6 tasks done
bmuenzenmeyer opened this issue Jan 8, 2016 · 12 comments
Closed
6 tasks done

dev branch: Add copy commands for public/styleguide assets #229

bmuenzenmeyer opened this issue Jan 8, 2016 · 12 comments

Comments

@bmuenzenmeyer
Copy link
Member

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
Copy link
Contributor

geoffp commented Jan 8, 2016

@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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Contributor

geoffp commented Jan 8, 2016

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Contributor

geoffp commented Jan 21, 2016

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

@bmuenzenmeyer
Copy link
Member Author

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
Copy link
Contributor

geoffp commented Jan 21, 2016

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.

@bmuenzenmeyer bmuenzenmeyer self-assigned this Jan 24, 2016
@bmuenzenmeyer
Copy link
Member Author

Just pushed this to https://github.com/pattern-lab/patternlab-node/tree/core-restructure-start

Remaining work on the top comment. This (and other changes to file structure) should be easier now that configurable paths are in

@bmuenzenmeyer
Copy link
Member Author

Finished grunt. switching over to gulp

@bmuenzenmeyer
Copy link
Member Author

This issue will close upon release to master

@bmuenzenmeyer bmuenzenmeyer removed their assignment Jan 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants