Implement Gulp workflow for Foundation 6

Yeah, that one is out of date. I've since moved to Gulp as it seems to be better supported as a built tool in the node world. Any chance at moving over to Gulp (for 6.x)?

Hi kevinquillen,

I just pushed a new method for managing the 6x branch that is in line with the way that zurb_foundation builds OOTB and best practices. It now uses Gulp, Bower, and NPM.

In addition, we do not have callback to the foundation files that ship with the base theme anymore in the sub theme, when you run bower install it will add those into your sub theme as you would expect from a normal foundatoin project. In additoin, the settings.scss file is now in the STARTER directory for overrides

So one problem we need to solve.

Right now, if you build a starter theme you still get css from the base theme. There is a checkbox in the starter theme to disable this, however there is one stylesheet that has some drupal specific changes that I still want.

One suggestion would be to add another checkbox in the theme to just disable foundation core css so you can use the one in your base. Another option would be to remove references to the foundation core all together in the subtheme and write docs about running gulp for the first time to get the css compiled into your sub theme.

alright, here is what I have come up. It's possible that I have a more complex situation than most. Basically, I need my subtheme be fully buildable and checked into a git repo, but also use the gulp/bower that zurb provides. This happens out of the box with the SCSS files, but not the JS files.

Since you dont want to commit bower_components to your git repo, this was my solution:

Add 2 NPM projects to the package.json, and also to my gulp file
"gulp-copy": "^0.0.2",
"gulp-concat":"^2.6.0"

Then executed a copy from the bower_components for the min js files that foundation requires to /js/vendor (these are in my git ignore still)

gulp.task('copy', function() {
return gulp.src(['bower_components/foundation-sites/dist/*min.js', 'bower_components/motion-ui/dist/*min.js','bower_components/what-input/*min.js'])
  .pipe(gulpCopy('js/vendor',{prefix: 3}));
});

Then I concatenate all those files in the order that foundation requires so that its a single file.

gulp.task('concat', function() {
  return gulp.src(['./js/vendor/what-input.min.js','./js/vendor/motion-ui.min.js','./js/vendor/foundation.min.js'])
    .pipe(concat('vendor.all.js'))
    .pipe(gulp.dest('./js/'));
});

then I run those functions in order (gulp copy, gulp concat)

This will give me a single file that contains all my js from foundation and add that file to my info.yml file.

Lastly I check both the boxes in the /appearance/[theme name]:
-Disable Base Theme CSS
-Disable Base Theme JS

Now my JS and CSS from Foundatoin and all vendor are in my subtheme. If I ever need to update foundation or add a new vendor js, I simply rerun my gulp tasks.

I wound up leaving them in bower_components, and not bothering with the copying stuff. From there I import them as sass to my subtheme, and the CSS is compiled anyway so there is no need to commit bower_components folder. Here is my starting Gulp workflow:

http://cgit.drupalcode.org/neato/tree/STARTER/Gulpfile.js?h=8.x-1.x

http://cgit.drupalcode.org/neato/tree/STARTER/scss/STARTER.scss?h=8.x-1.x

I used to copy things around, but eventually concluded it was a lot to keep track of - especially when the sub theme can just pull them in and build it up into compiled output. That is assuming your subtheme keeps the parent base theme. I found it easier to reason about the external libraries that way.

Do you mean Gulp, @Rob_Feature?

Foundation 6 doesnt use Grunt out of the box any more, it moved to Gulp.

We need to make a few decisions here:
My method (running bower install to get the JS and CSS locally, then move it around using gulp) works now, but it means all the foundation code is coming from the subtheme. I think there are many advantages to this as you get better control over specific versions used in your theme. Its (mostly) this way now for the CSS anyway so it makes sense to me. This method also allows you to simply add in new NPM or bower packages and maintain consistancy in a single structure.

We could do this in the base theme and reference how we are doing it now though.

Any thoughts?

We could do this in the base theme

Yes, I am all for this. The reasoning is it should be easy to spawn a lot of subthemes, and all of them will be locked into using the same version of Foundation (which would be whatever version indicated in bower.json). If you ran bower update, you would get any updates upstream, but that is totally optional. I have been down the path of copying assets around to folders after bower install and or in a grunt task, it becomes really difficult to manage.

Also, if it is not set in the base theme, that means every subtheme gets copies of the same library which is a lot of overhead.

6.x branch has been updated with some changes:

• Deleted config.rb
• Updated bower.json (changed name to STARTER, to be replaced)
• Marked foundation dependency to be 6.2.0 in bower.json
• Added composer.json

In my opinion, the gulpfile should ship with default tasks that serve the most basic needs of themers:

• Generate & compress CSS (with sourcemaps)
• Generate & compress JS (with sourcemaps)
• Run drush cc css-js on build (so aggregation can stay enabled, and the sourcemaps can be used for debugging)
• Optionally enable Browser Sync (maybe not important? I find it useful)
• Optionally trigger drush rebuild when twig files change
• Optionally include js linter task
• Optionally include css linter task

Along with that, we can save ourselves LOC by defining SASS includes inside of STARTER.scss instead of gulpfile.js. That way all gulp is concerned about is the main scss file, and where to generate the CSS to.

Also, I find it useful to include a configuration.js (can be called whatever) so that a developer can change variables pertinent to their environment without committing it back to their local project (i.e. multiple people working on one theme, who's drush site alias command could be different from everyone else). Said file would be .gitignored. We could also provide the .gitignore with that file in the STARTER. I would almost say STARTER needs a .gitignore itself for bower_components and node_modules - these are such massive directories that they should not be getting committed into a project (but that's debatable).

@kevinquillen We should definitely look into beefing up the gulpfiles, I like the idea of optional features too.

@kevinquillen,

I am having a killer time trying to get gulpf source mapping and nested css to work.

If anyone could post an example gulpfile.js file that would be super helpful.

forgot to include patch file.

Here is a patch that expand the available tasks for STARTER gulpfile.js, though this still need more work, and it would be great if we have the patch from issue #2723275: Move zurb_foundation.scss to STARTER theme.

Tasks done:

• Generate & compress CSS (with sourcemaps)
• Run drush cc css-js on build

Tasks needs work:

• Generate & compress JS (with sourcemaps)
• Enable Browser Sync
• Trigger drush rebuild when twig files change
• Include css linter task
• Include js linter task

Patch appears to remove rimraf from package.json, that is needed to remove .info files from node_modules folder so as to not cause a segfault. As far as I know there was ongoing work in core to rectify that from happening (was still happening in 8.0.x for me last fall). If they have fixed it, then we can remove it, as well as the postinstall script line.

For sourcemaps, I found that you have to disable CSS/JS compression in Drupal for that to work. Then Chrome tools is able to show you the SCSS that generated the CSS.

@kevinquillen yes removing rimraf was a mistake since the issue still no solved #2329453: Ignore front end vendor folders to improve directory search performance, though I didn't notice that since some dependencies do install it, I have added it back.

I have also added support for a sass lint task, and made compressing CSS and generating a sourcemap the default for build and watch.

Also the lint shows around ~60 warnings using .scss-lint.yml config from zurb-foundation repo, I think this needs to be done in another issue.

Tasks done:

• Generate & compress CSS (with sourcemaps)
• Run drush cc css-js on build
• Include css linter task

Tasks needs work:

• Generate & compress JS (with sourcemaps)
• Enable Browser Sync
• Trigger drush rebuild when twig files change
• Include js linter task

Upload a new patch with no changes (the same as number 21) using diff instead of format-patch to become easier to read.

I applied the patch without issue and ran through creating a sub theme using drush followed - `npm install` and - `bower install`.

The patch is mostly an update to the most recent(mostly) packages so should be safe to commit.

#2657544-8: Implement Gulp workflow for Foundation 6 Would be a valuable addition as the separation of theme/sub-theme isn't ideal at the moment but that can be a different issue & discussion.

I have been using this and having some issues with JS which may or be not caused this patch but just to be safe have put back to need review.

@kevin

Thank you so much for doing this! The Gulpfile is by far the thing that trips me up the most when trying to develop with the Foundation Theme.

PLEASE PLEASE commit this gulp file as I also believe this is a critical workflow that is confusing for some people. You can spend hours editing your gulp file :)

I was receiving the errors was well until I realized that you need to re-run the installation of bower and npm.

Here are the steps if you are applying this patch:

1. Apply Patch
2. cd into theme
3. bower install
4. npm install
5. npm run

Committed - thanks everyone!