Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Switch from Grunt to Gulp #1138
I've been doing some Gulp.js testing this weekend, and while it's working really well, it looks like when there's an error, the gulp console has to be quit and then restarted. Also, on my mac, it doesn't notify the terminal, or the user, like grunt does.
I'm wondering if maybe we should add gulp-notify and/or gulp-plumber to help handle error handling?
Other than that, it's working pretty well, and it IS noticeably faster.
referenced this pull request
Sep 8, 2014
referenced this pull request
Sep 12, 2014
Just sent over a PR that enhances the gulp functionality. I tried not to change too much before we discuss.
There are some things I have identified about your build process that are very odd and perhaps we should take this opportunity to correct while we are introducing breaking changes:
"You keep using that word. I do not think it means what you think it means."
and presumably if you wanted to add some vendor'd css
The whole point of vendoring is so third-party code is clearly separated from first-party source code. The directory structure should look like this:
Where vendor is ideally completely blank. If you are checking things into a vendor folder it's because you absolutely cannot use your package manager to grab them or you did some monkey patches or something.
Mixing compiled files with src files
How exactly do you expect to get these theme files to the server? Obviously the compiled files are not checked into source control, so are you manually uploading them? This doesn't work with capistrano, which is what bedrock uses. This means bedrock-ansible + bedrock + roots is DOA without checking compiled files into source control.
The final layout should look like this:
and then use a capistrano task to rsync
I'm still catching up to all these rapid fire changes and switching things over to gulp... but does this not output the wiredep-ed main.less to the dist folder, while the globs being processed by cssTasks are coming from the assets folder? I tried running the build after this change but my main.css was not being built from the wiredep-ed main.less, rather the original.
The logic here for Sage seems to favorise Bower and I'm totally for it in general.
I was updating an old Roots-based theme before the Modernizr custom build and I was asking myself : why build a custom Moderniz and save a few kB (half, maybe), instead of using its main CDN with the latest complete build... so that people could have it in their cache already.
Would it be correct to consider Modernizr like a "WP essential" (and above WP..) like jQuery, and grab it through a CDN ?
If not, why not merging the custom build into scripts.min.js ?
... just trying to save 1 query for our mobile users there ;)
Keep up the awesome work !
Good comments, thanks for reviewing the code. It really helps us a lot.
Assets definitely need to be version locked. I'm pretty sure you can do this with the CDN hosted version but having the CDN auto-update modernizr for you is asking for trouble. Just wanted to specify that requirement.
My only concern is that if a plugin specifies modernizr as a dependency and it needs to jump to the header or something dumb like that. Idk enough about caveats with plugins but @Foxaii @swalkinshaw @retlehs can probably help me understand.
So there are 2 points :
So why not using a CDN Modernizr .js in HEAD ?
Whatever we do as far as CDNs go:
We need to implement a way to reconcile the bower included version of a dependency (jQuery) with the CDN version of it. If I include version 1.11.1 of jQuery in my bower.json, then the CDN needs to be set to load cdn.google.com/whatever/jquery/1.11.1/jquery.js.
I think we can forego the html5shiv entirely and drop support for IE 8. Users of IE 8 are used to pages looking like shit because everyone has dropped support for IE 8, including the upcoming version of Bootstrap.
Android 2.3 native browser support also seems arbitrary since it's used by such a small fraction of users, but that's unrelated to modernizr and html5shiv so I won't dwell on that here.
By loading modernizr in the footer we have already dropped support for IE 8. As such: if we aren't obnoxious about it, I am ok with not jumping through hoops to support IE 8. If you have a project that requires IE 8 you can literally just copy paste this into your head:
<!--[if lt IE 9]> <script src="https://cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.2/html5shiv.min.js"></script> <![endif]-->
And you are back in business.