[buddypress-trac] [BuddyPress Trac] #5160: Use gruntjs to generate minified versions of the js and css files everywhere.

[buddypress-trac]

#5160: Use gruntjs to generate minified versions of the js and css files
everywhere.
-------------------------+------------------
 Reporter:  enej         |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  2.1
Component:  Core         |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+------------------

Comment (by netweb):

 Replying to [comment:11 boonebgorges]:
 > > This can be coded around. We don't need to place the burden of
 SCRIPT_DEBUG on the developers running from src.
 >
 > I'd be curious to hear your thoughts on how this should be coded around.
 I see that WP is doing this:
 https://core.trac.wordpress.org/browser/tags/3.9/src/wp-includes/script-
 loader.php#L53 But we don't have the same luxury, because we use the same
 constant `SCRIPT_DEBUG`, and it's already been defined by the time WP is
 loaded.

 bbPress is also using `SCRIPT_DEBUG`, if it's defined in `wp-config.php`
 then don't load
 [https://bbpress.trac.wordpress.org/browser/trunk/src/templates/default
 /bbpress-functions.php#L121 (src)] the minified CSS or JS

 > In any case, we want to support cases where BP /src/ is run out of
 either /build or /src WP, so we wouldn't want BP to hijack the constant
 even if it could.
 Running WordPress from the the 'develop' repo's `/src` folder will cause
 various issues, for example the 'MP6 admin colors', in the `/src` folder
 there is only the `.scss` files, there is no `.css` files.

 Further we have taken bbPress down this same route, our included 'MP6
 admin colors' scheme does the exact same thing, we only have the `.scss`
 files in the `/src` folder then compile the `.css` files as part of the
 build process to the `/build` folder.

 > So, we could wrap `SCRIPT_DEBUG` in a function like `bp_script_debug()`,
 and in that function do a similar /src check to see if we should accept
 the value of `SCRIPT_DEBUG` or whatever. Then we'd have to swap out every
 current call to `SCRIPT_DEBUG` to use the new function.
 I don't think this is needed, essentially if you are developing for
 WordPress core, BuddyPress or bbPress you should be running each of these
 using the `/build` folder of each and patch against the `/src` folder.

 The `grunt watch` task makes this workable as any changed files in the
 `/src` folder when modified will be copied to the `/build` folder with any
 extra tasks such as RTL'ing or minifying CSS will also occur depending on
 the file type.

 > I'm fine with doing that, but I will note that there are very few people
 running trunk in production anyway, and I would assume that they know what
 they're doing. We're a different beast from WP in this way.
 The bbPress 'loader' is a 'workaround' for people who are running `/trunk`
 and who have not run the 'build' task, it will load bbPress from the
 `/src` folder so the site does not 'break' because bbPress /trunk cannot
 load. They will have issues with not having any RTL CSS, minified LTR/RTL
 CSS or JS and no MP6 admin color schemes.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5160#comment:15>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac