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

Splitting up the grunt file #1073

Closed
davebowker opened this issue Jun 30, 2014 · 9 comments
Closed

Splitting up the grunt file #1073

davebowker opened this issue Jun 30, 2014 · 9 comments

Comments

@davebowker
Copy link

Any thoughts on splitting up the grunt file into small chunks that we can manage better when we fork it? EG https://github.com/creynders/load-grunt-configs

I know each dev will have their own preferred/required grunt tasks they'll need to run and this might save from having one gigantic gruntfile.

I started to implement the same in my theme starter before I took a serious look at roots. (https://github.com/davebowker/Guts/) See the gruntfile, and see each task split up in the configs folder.

Would be happy to write this update if it's a feature you'd be interested in.

D

@QWp6t
Copy link
Sponsor Member

QWp6t commented Jun 30, 2014

There was a PR for this in #970, and this was the boss's response:

thanks, but going to pass on this. our gruntfile isn't that long and splitting it up into separate files makes it not as friendly for those that are new to grunt

I personally think before we invest any time into making changes to Gruntfle.js, we should look into whether we even want to continue using Grunt. There are other taskrunners out there, and it might be time to start investigating whether a switch to one of those would be best. That's not to say I have any particular issue with Grunt. I just think it's something we should explore given that there are other contenders now.

@davebowker
Copy link
Author

The contents of this theme implement a lot of things that could confuse a beginner dev. For instance, using Bootstrap inside of WordPress to build a theme is non-standard to a beginner.

Looking over functions.php, you're doing pretty much the same thing there. My opinion is that an entry level beginner:

A) May find it easier to understand with it being split up. If each file focuses on a single task and they need to edit something then they know exactly where to look to attempt updating that task.
B) Wouldn't necessarily need to know that grunt is split up. If they completely don't understand grunt then all they need to know is to run it from the command line. It wouldn't matter for these users whether it was split or whole, but for those that do know it would be easier to add and maintain new tasks.
C) Would have a better understanding trying to use _S than this.

My 2 cents.

Edit: Good point on other taskrunners, however there'll always be something new. Unless they do something that Grunt can't which is absolutely crucial to this project then I'd stick with grunt. It's been around long enough that those who've used it a basic level can get to grips with it in this.

@JulienMelissas
Copy link
Sponsor Contributor

Hmmmm...

Personally, the reason why I thought this was a bad idea on first read was because of the same reason as Ben's response, but the more I think about it, and the more we're using partials on v7 the more I think it's a good idea. I think it would be worth revisiting.

Root's gruntfile by default isn't that long BUT once some of us are done with them on a big project they can be pretty hefty!

@davebowker, I'd say if it doesn't take you forever fork the 7.0 branch and come up with something! I'd love to see it anyways.

@retlehs
Copy link
Sponsor Member

retlehs commented Jul 1, 2014

I'm open to this.

Sent from my iPhone

On Jun 30, 2014, at 7:22 PM, Julien Melissas notifications@github.com
wrote:

Hmmmm...

Personally, the reason why I thought this was a bad idea on first read was
because of the same reason as Ben's response, but the more I think about
it, and the more we're using partials on v7 the more I think it's a good
idea. I think it would be worth revisiting.

Root's gruntfile by default isn't that long BUT once some of us are done
with them on a big project they can be pretty hefty!

@davebowker https://github.com/davebowker, I'd say if it doesn't take you
forever fork the 7.0 branch and come up with something! I'd love to see it
anyways.


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

@davebowker
Copy link
Author

I've got some time at the end of the week. I'll take a look.

@davebowker
Copy link
Author

First stab here. Thoughts.

#1074

@markthethomas
Copy link
Contributor

Personally, I've found that trying to split up gruntfiles can lead to headaches and lots of jumping between files. Relatively speaking, this one isn't that long (see the generator-angular one at ~446 SLOC vs. roots at ~233 SLOC) compared to some larger projects that have made extensive use of grunt. Maybe it's just me, but the current length seems better to work with than working with a number of smaller files. If people really need to split them up, that can easily be done on a user by user basis, don't you think?

@davebowker
Copy link
Author

Hey Guys,

I've updated this for version 7.0.0, however there's a slight issue I'm having and wondered if anyone could help. Currently, this is the only thing that's left to do on this improvement.

Files are here: https://github.com/davebowker/roots/blob/master/Gruntfile.js

Everything is split up and working fine if you remove uglify, watch and concat as these are requesting files from the array jsFileList. It's passing in that jsFileList that I'm struggling with.

I'm fairly new to grunt, I think this should be a quick fix but my mind has collapsed on it. Would be great if someone knew how to fix it.

Thanks!

@davebowker
Copy link
Author

So I fixed that issue. Latest files are in this pull request. #1081

@retlehs retlehs closed this as completed Jul 26, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants