[buddypress-trac] [BuddyPress Trac] #5160: Use gruntjs to generate minified versions of the js and css files everywhere.
noreply at wordpress.org
Wed May 7 14:25:32 UTC 2014
#5160: Use gruntjs to generate minified versions of the js and css files
Reporter: enej | Owner: johnjamesjacoby
Type: enhancement | Status: reopened
Priority: normal | Milestone: 2.1
Component: Core | Version:
Severity: normal | Resolution:
Comment (by netweb):
''Below is an extract of my original reply I was going to submit before I
realized what I wrote above in the previous comment.
I'm adding it as a personal opinion on how I see and use the build tools
included in WordPress and bbPress.
(I have removed anything pertaining to the code changes I had previously
Replying to [comment:49 DJPaul]:
> Consistency with WordPress' Grunt process is a stronger argument than
being consistent with bbPress', as bbPress' adoption of Grunt is still
pretty new and will likely be iterated on as better ways of working are
discovered. We shouldn't hold some idea that it's important for our build
scripts to be 100% identical with our sister projects'; we can't let that
stop us from adopting changes that work best for BuddyPress.
Indeed they do not need to be identical and both should use the tools that
best fit the needs of each project, that said, they need to be compatable,
maybe complementary is a better term. Developing with bbPress and
BuddyPress at the same is often needed by both projects. bbPress needs to
ensure our BuddyPress integrations do not break and BuddyPress needs to
ensure the bbPress forum implementation does not break.
Both bbPress and BuddyPress inherit initiatives from WordPress upstream
such as Trac updates, inline docs, coding standards, contributing
guidelines and this new build setup I don't see as any different,
compatability, interoprability and consistency upstream is extremely
important. bbPress' Grunt process is quite similar to WordPress' and I
would go one step further and say 'in sync' for the most part, if I see
improvements to be made I look to implement the changes in both bbPress
and WordPress and that now would also extend to BuddyPress.
Dogfooding is the approach I have taken with both WordPress and bbPress
'develop' repo's. I see three components to the these Grunt powered repos.
1. A folder which contains the core source files
2. A folder which contains compiled source files
3. A process to create a full release of the package for distribution.
Those descriptions above I purposefully left out the term 'build' as I see
primarily the two tasks `grunt build` and `grunt build-release` as
significantly serving two vastly different purposes. The later `grunt
build-release` runs all the grunt tasks needed to copy, minify, RTL,
makepot, validate and unit test to facilitate the creation of a complete
release to be deployed to the WordPress plugin SVN repo.
The former `grunt build`, I don't see this as a tool to generate a
'release build', I see this as a tool to create a full working copy of the
source with compiled assets that I use for primary development of bbPress
(and WordPress). What this allows me to do is in the true spirit of
dogfooding is to use the identical same package end users will use once
released. I can set (or unset) `define( 'SCRIPT_DEBUG', true );` in `wp-
config.php` as needed allowing for easy debugging of non minified CSS or
JS assets, full RTL CSS is also available when testing with the RTL plugin
tester for example.
* All of my WordPress 'trunk' installs use the `/build` folder as the
documentroot/webroot, without it many asset types are not available such
as MP6 themes
* All of my bbPress development uses the `/build` folder as the plugin
root, again, without the built project compiled MP6 themes are unavailable
* The `/src` folder is used for all code changes with most changes
deployed to the `/build` folder live using `grunt watch` or in bulk with
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5160#comment:57>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac