[buddypress-trac] [BuddyPress Trac] #5821: Update grunt build tools - Fixes JS & CSS build process
noreply at wordpress.org
Wed Aug 20 01:07:41 UTC 2014
#5821: Update grunt build tools - Fixes JS & CSS build process
Reporter: netweb | Owner:
Type: defect (bug) | Status: new
Priority: highest | Milestone: 2.1
Component: Core | Version:
Severity: blocker | Resolution:
Keywords: has-patch |
Comment (by netweb):
Replying to [comment:2 DJPaul]:
> I've only time to eyeball the changes right now, but I think it looks
OK. Thanks for the patch, netweb.
> The line ending and other whitespace changes are always going to be
committed separately from anything else, so a separate patch for those
would have been helpful, but at least with Git, we can be selective with
files during commits, so this isn't a big deal.
Due to weird cross platform end of line issues, the BuddyPress SVN repo
would always compile two RTL CSS files with new line endings, not so via
the Git repo which was a strange issue but moot now.
Whilst creating this patch and verifying CSS and JS file integrity it made
sense, it also saved me having to revert the SVN repo constantly every
time I ran the Grunt tasks testing this patch.
> sort the tasks alphabetically
> Thanks for not mixing this up into this patch. :) The original idea was
to have the tasks listed in the order that they're executed in (as much as
possible, anyway) so that it's easier to read the file and better
understand what's going on (without having to refer to the registerTask
> Listing things alphabetically, especially considering that some of our
commands run in SOURCE_DIR and some in BUILD_DIR, I think will make things
more confusing. Therefore I don't think we'll want to do this with
BuddyPress, unless the other core devs feel very extremely strongly about
having this in alphabetical order.
As you point out some tasks use both `SOURCE_DIR` and `BUILD_DIR` and the
updated `grunt jsvalidate` task is a prime example, `grunt
jsvalidate:src` is the first task ran and the `grunt jsvalidate:build`
task is the eleventh.
A console output which can be quite long, I don't want to have to scroll
to the top of the console to see which position the failed task is in,
commit to memory, or have to read the task order to guesstimate where it
might be in `Grutfile.js`, I'll reference the failed task by it's name and
then go and find the task, creating this patch I was wasting loads (we are
only talking seconds) of time scrolling up and down (and past) tasks where
I kind of expected them to be, it's a trivial issue only saving seconds,
but I find it illogical in not being sorted A-Z ;)
> > Removes unused grunt-phpunit
> Are you sure this isn't used by the `phpunit` task inside the `test`
Yes, I see where you are coming from in thinking that though, kind of
confusing and removed in [bbPress5414] and has never existed in WordPress
Core yet all three projects basically all share the same Grunt PHPUnit
The NPM package [https://github.com/SaschaGalley/grunt-phpunit grunt-
phpunit] is quite a different beast and task configuration vastly
different, it was looked at to fix #5627/#WP27343 but there is currently a
bug that won't allow the passing of arguments to separate single site from
multisite tests along with some challenging console output display issues
The `grunt.registerMultiTask( 'phpunit'` task runs both `phpunit:default`
and `phpunit:multisite` tasks passing the command `phpunit` and `args` to
`grunt.util.spawn` and actually executing the PEAR command `phpunit` with
args, if you don't have the PEAR PHPUnit package installed and in your
system path the task fails.
You could say it is similar to how `grunt:exec` works, a Grunt MultiTask
`grunt.util.spawn` could probably possibly replace `exec:bbpress` and
`exec:bpdefault` tasks, that's for another day though.
// The command to execute. It should be in the system path.
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5821#comment:3>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac