-
Notifications
You must be signed in to change notification settings - Fork 32
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
Grunt #14
Comments
We're not going to convert existing projects to gulp in a hurry, so maybe we can bookmark that discussion and focus on Grunt and how best to use it. |
|
Outside of Grunt vs. Gulp (or even using a Makefile), there are a few specific capabilities that I think we should be using in all of our projects:
Are there any other core needs? |
A scenario that may come up (that I know at least flapjack wants) is page-specific JS and possibly styles, so all site-JS and CSS isn't loading per page. I'm not sure if you want to include that scenario here, but in that case there wouldn't necessarily be a single stylesheet/js file.
Pre-commit could be developer preference as well? Tests can take a loooong time and sometimes it's preferable to push code to Travis and continue working while the tests run remotely. On commit could be really annoying. If this is happening on a git-hook, pre-push would be better I think (if that's possible with git-hooks—I don't know). |
This is a good approach. We can certainly bundle common site wide files and also bundle section specific ones.
Pre-commit is what I typed out, but yes, I agree that could be slow and annoying. Pre-push and/or Travis is more what I had in mind. |
Grunt tasks should probably be implementation-agnostic. For example, I'm working with JS linting right now, and the linter is ESLint. I have a task called If its important to specify the implementation (like if for some reason the project required two linters), the grunt tasks could use subtasks. E.g. The same argument could be made for things like the Thoughts? |
👍 standardizing to |
So digging into this a little deeper I realized it's kind of set up like this already. For example, in the FlapJack gruntfile, there is this line:
So the task is describing what it's doing (
The annoying thing here is now there are three tasks We could remove the need to specify an implementation in the task list altogether with:
I wish I could get this to be more concise, but even though it's more verbose, it would eliminate differences in this part of the gruntfile if two different projects used different linters. With the grunt config I'll show in a moment this would allow a general The actual config for this (in
Or if you wanted both ESLint and JSHint available:
|
Another reason I love Gulp, task names aren't tied to plugins and it's as easy as
You can swap out your linting plugin and the task itself stays the same. |
Reading up on grunt best practices I found http://www.thomasboyt.com/2013/09/01/maintainable-grunt.html, which talks about breaking up grunt config files. This can be achieved with https://github.com/firstandthird/load-grunt-config. I kind of like this approach, as the huge Gruntfiles we have are hard to parse. Breaking them apart means updates can be on a per-task basis, without a superficially opaque diff for the whole Gruntfile whenever there's a change. This also means projects can have identical Gruntfiles, but still differ in their implementation of tasks (if desired). For instance, one project could concatenate files different from another project, but they could both have a |
@Scotchester Hah! So let me re-phrase... Any strong opinion about offloading the implementation of config loading to |
I would be all in favor of it 👍 |
Discussed 07/17 in front-end meeting. Closing issue. |
How are we using it, how can we use it better + more deliberately?
Initial discussion
The text was updated successfully, but these errors were encountered: