Next major version

[trykickoff]

Next major version

[mrmartineau]

Styleguide improvements

See #48

UX improved for the entire framework

This is a fairly large piece of work that extends out to the Yeoman generator & Statix. I would like to make it much more intuitive to use the framework. Code and configuration should be easy to find.

[mrmartineau]

@ashleynolan I have been using gulp a lot on some personal projects and feel that it could benefit Kickoff. If I could get the exact same functionality as we have with Grunt, but use gulp instead, would you consider it?

[nicbell]

What does Gulp do better?

Have you considered including a minimal grunt or gulp file and just having what is needed to build Kickoff. A lot of what is included in Kickoff's grunt config is workflow/project specific.

For example I strip browser-sync, connect and jquery-builder straight away and add githooks. That prescribed workflow is not relevant when Kickoff's purpose is a SASS framework, maybe that specific workflow should be a separate TMW project with kickoff as a dependency?

[ashleynolan]

Would be worth going through the benefits of switching.

I don’t really mind either way if there’s a good use-case for it and it can do everything that Grunt can. If we do switch, it would be a shame to lose the grunt setup work, so maybe would be good to consider how we could keep that, even if we no longer really update those files in future.

Let’s chat about when you get back from holiday.

[mrmartineau]

Gulp is very similar but I have found it to be much easier to use whilst also being more powerful. I have started a next-gulp branch and am in the process of converting all Grunt tasks to gulp tasks. See the example gulpfile here.

I have also had problems recently with sourcemaps for Sass (when using grunt-sass), because they are broken in node-sass, but with gulp, sourcemaps are an entirely separate package which means I can add sourcemaps to anything without needing their implementation to work.

Using gulp for javascript tasks is also better in my opinion. In the gulpfile linked-to above, I have the existing JS file list concatinated, sourcemapped and uglified just as we do in Kickoff and on my personal site I use Browserify. You should be able to see that the configuration for each of these is much more simple than the grunt equivalent.

I will keep progressing with the gulp branch and would like to count on you guys, and anyone else, to test to see if it's worth the switch. Hopefully, the only real change to users would be to switch from typing grunt serve to gulp serve in their CLI.

[mrmartineau]

I have also added a flag (variable) for when the site is in production and you need to minify everything. See https://github.com/tmwagency/kickoff/blob/next-gulp/gulpfile.js#L33. It negates the need for separate tasks like grunt dev & grunt deploy. As @munkychop mentioned, this could actually be an environment variable or another setting in your CI setup..

[nicbell]

Also, is it worth considering just using npm scripts? It will mean better access to plugins.

http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/
http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/
https://blog.cesarandreu.com/posts/give_npm_scripts_a_chance

[mrmartineau]

While I think npm scripts might be a good way to run tasks, with certainly more options available to it, I do not think using it will be as beneficial as using Grunt or gulp purely because they are both extremely well documented and have massive developer support.

[EDIT] I also forgot to mention that it then makes it easier for devs to use Kickoff.

[mrmartineau]

I thought I would post an update on my progress.

gulp

I have spent a fair amount of time on the next-gulp branch and have come to the conclusion that we shouldn't switch to gulp yet. While gulp provides many benefits over Grunt, they are not substantial enough for us to make the switch at the moment. One of the main issues I found is that there is no comparable task for Grunticon; I know Filament Group are working on a standalone library for Grunticon but it is not ready for production yet.Our existing Grunt setup is so comprehensive and well-documented that it would not make sense to switch.

Grunt

The Grunt config/options is being tidied and the tasks are being refined.

Assets

There has been some movement of static assets (CSS, images & JS). We are moving all source files into ./assets/src and all compiled code will reside in ./assets/dist. This should make it more clear as to what-goes-where and more intuitive to use.

Javascript

Do we use Browserify by default? @nicbell @ashleynolan @munkychop
Do we need to update the existing js setup?

[ashleynolan]

All look good.

As for the JavaScript, I think it should still be an optional branch. Advanced users should ideally be using the generator, and then it’s pretty much included anyway with a Y/N switch.

[mrmartineau]

@ashleynolan good point. We should push most users to make use of the generator.

[nicbell]

I like Browserify + npm but does it have everything that bower has? Or will we mix the two?

[mrmartineau]

it probably doesn't have everything bower has but if you're using Browserify then you're going to need the script to use module.exports otherwise Browserify won't work, no? Also you can place bower packages in the npm_modules folder & require them using the normal procedure. Its a bit dirty but it does work. Most worthwhile packages are on npm IMHO.

[munkychop]

It's possible to use debowerify as a Browserify transform for Bower packages that aren't CJS compatible. If the Bower packages are CJS compatible then they can either be require'd directly or shimmed.