Menu icon Foundation
Git cloned F6 repo workflow? (JS imports alternative?)

Hiya

Really loving F6 so far! It's also introduced me to Gulp and semi automated workflows – I like to learn new things!

So, I have a 'best practice' kind of of question.

I've played around the CLI to install foundation, which works great, but the way I currently prefer to work is to git clone the F6 (or Foundation Zurb template) repos and use those as my starting point. This way I can pull in any changes made to foundation git repo without starting all over again,

What I'm wondering when working this way, is, what's the best approach for customising which Foundation JS modules / plugins get included in the final production build and which don't. With the SCSS files it's not a problem as I just comment out which modules I don't want to be imported or just rely on UNCSS in a production build to strip out any unused CSS.

However with the JS it appears that by default all JS modules get included. And within the Foundation Zurb Template, as there are no @!imports for JS, the only way to exclude various JS modules from the build appears to be to physically remove the JS files from the folder (foundation-zurb-template / bower_components / foundation-sites / js / ).

This unfortunately means when ever I pull any updates from the zurb repo the changes I've made within foundation-zurb-template / bower_components / foundation-sites / js / get over written.

I'm sure I must be missing something? Whats the best way to work with F6, whilst also allowing to keep it up-to-date via Git?

Hope that makes sense!
Many thanks
Stef

foundation-sitesfoundation 6jsimport

Hiya

Really loving F6 so far! It's also introduced me to Gulp and semi automated workflows – I like to learn new things!

So, I have a 'best practice' kind of of question.

I've played around the CLI to install foundation, which works great, but the way I currently prefer to work is to git clone the F6 (or Foundation Zurb template) repos and use those as my starting point. This way I can pull in any changes made to foundation git repo without starting all over again,

What I'm wondering when working this way, is, what's the best approach for customising which Foundation JS modules / plugins get included in the final production build and which don't. With the SCSS files it's not a problem as I just comment out which modules I don't want to be imported or just rely on UNCSS in a production build to strip out any unused CSS.

However with the JS it appears that by default all JS modules get included. And within the Foundation Zurb Template, as there are no @!imports for JS, the only way to exclude various JS modules from the build appears to be to physically remove the JS files from the folder (foundation-zurb-template / bower_components / foundation-sites / js / ).

This unfortunately means when ever I pull any updates from the zurb repo the changes I've made within foundation-zurb-template / bower_components / foundation-sites / js / get over written.

I'm sure I must be missing something? Whats the best way to work with F6, whilst also allowing to keep it up-to-date via Git?

Hope that makes sense!
Many thanks
Stef

Erik M almost 4 years ago

Hey Stef!

That makes sense. We didn't build a flow into the foundation-sites repo that easily removes the JS for your situation (... yet!). The easiest way right now to customize the included JS is to use the customizer located at http://foundation.zurb.com/sites/download. However, for the workflow you use, that isn't a great solution. So I have a few comments.

  1. Physically removing the JS files is a good solution temporarily
  2. I will discuss with the team editing gulp/javascript.js so that the part in the screenshot below has a set of .js files that can be modified, instead of using the *.js to grab every file.
  3. I recommend forking the repo, and setting the upstream to our repo to keep your work up to date, without having to constantly resolve the changes you made with the vanilla framework. Details on this here: https://help.github.com/articles/configuring-a-remote-for-a-fork/ or more detailed here: https://help.github.com/articles/fork-a-repo/

Basically I think you would be better off forking, and using an upstream for updates.

If you are in a hurry to fix up your javascript issue, you can make those changes to the gulpfile locally.

http://prntscr.com/95edci

Hope that helps! Let me know if you have any questions!

Stef Tock almost 4 years ago

Great reply - thank you Erik.

Glad I haven't missed an obvious 'trick'!

Yeah, I a was wondering about including all the js files within the gulpfile instead of the catch-all wildcard that's there now.

Mind you it's not a massive issue to have to manually manage and move the js files either - part of me is lazy and part of me wants to see just how easy / quick / automated the process can be.!

I'll look into forking the repo instead - I'm still learning all the ins and outs of git / version control too. So forking would be considered best practice? Thanks for the links. Whilst f6 was in beta, and in the past few days thee have so many changes ( you've all been super busy! ) it felt important to keep up to date. I guess that will be less imperative as time moves on and f6 settles in even more!

Thanks again
Stef

Erik M almost 4 years ago

Hey Stef!

Glad that helps. In Git, the best practice to work locally while constantly stay up to date with an external repo is forking, and setting an upstream. Basically its because it allows you to work locally, while still keeping up to date with a main repo. You can even request to add your changes into the repo you forked! It's a really useful technique for collaborating. The best way to learn this stuff, is to have something to try it on! If you are interested in practicing, you could try:

  1. Fork foundation-sites
  2. Set the upstream
  3. Change the gulpfile as described above
  4. Push changes to your fork
  5. Pull request to put changes you made into the main repo.

Basically, that would allow you to change the gulpfile and actually become a collaborator on foundation-sites yourself! If you are interested in that, give it a try and let me know if you have any questions. Otherwise, I will talk to the team about adding those changes ourself :). A few resources are linked below:

I realized I omitted a link that would probably more succinctly describe this:

https://help.github.com/articles/syncing-a-fork/

combined with from the previous post:

https://help.github.com/articles/configuring-a-remote-for-a-fork/

Pull requests:

https://help.github.com/articles/using-pull-requests/#fork--pull

Using the upstream technique should be the same as using the bower or npm package. Those point to the foundation-sites repo's masters branch. It might be easier to install via bower and use bower update from time to time.

I totally understand you wanting to keep up to date given how many changes have been added in the last week. I think things will settle down now that we are released. Thanks again for telling us about your situation though.

Keep up the great work!
Erik

Stef Tock almost 4 years ago

Thanks Erik.

I find it confusing that clone and fork effectively seem to do the same thing? (fork is pretty much a github server-side clone right?)

Anyhow, going to have a go updating a fork and sending a pull request today – fingers crossed.

Thanks for the encouragement!

Stef