Make WordPress Core

Opened 10 years ago

Closed 5 years ago

Last modified 5 years ago

#29546 closed enhancement (wontfix)

grunt uglify for plugins and plugin developers

Reported by: mattyrob's profile MattyRob Owned by:
Milestone: Priority: normal
Severity: trivial Version:
Component: Build/Test Tools Keywords: has-patch
Focuses: Cc:


A few months ago I submitted a ticket to allow plugin developers to run JSHint on heir plugins.

I now propose that we add uglify to that so the JS can be minified. The attached patch creates uglify:plugins.

In addition, I've noticed that if a 'dir' was not specified the task ran on the entire plugin folder, I think it may be better to bail for both uglify:plugins and jshint:plugins so the attached patch adds that also.

Attachments (5)

29546.diff (1.3 KB) - added by MattyRob 10 years ago.
29546v2.diff (1.6 KB) - added by MattyRob 10 years ago.
29546v3.diff (2.0 KB) - added by MattyRob 10 years ago.
29546v4.diff (1.9 KB) - added by MattyRob 10 years ago.
29546v5.diff (1.9 KB) - added by MattyRob 10 years ago.

Download all attachments as: .zip

Change History (22)

10 years ago

#1 @MattyRob
10 years ago

  • Keywords has-patch added
  • Severity changed from normal to trivial

#2 @nacin
10 years ago

  • Milestone changed from Awaiting Review to 4.1

We can/should assign this closure to a variable for use in both places, I think.

10 years ago

#3 @MattyRob
10 years ago

Is v2 patch better?

#4 @nacin
10 years ago

Ah, I mean the actual function( dirpath ) { . . . }.

10 years ago

#5 @MattyRob
10 years ago

More like the v3 patch then?

10 years ago

#6 @MattyRob
10 years ago

v4 patch removed the BUILD_DIR from the uglify:plugins addition, I think it may make more sense to minify the javascript inside the plugin rather than moving out to the build/ folder.

#7 @GaryJ
10 years ago

Little typo in the patch: requite => require.

10 years ago

#8 @MattyRob
10 years ago

v5 patch fixes reported typo.

This ticket was mentioned in IRC in #wordpress-dev by netweb. View the logs.

10 years ago

#10 @jorbin
10 years ago

I'm not sure I like this idea. I think that uglify and other modification tasks are ones that should be owned by individual plugins and not by core. I like what [28798] did to make testing easier, but I view this differently.

Right now, develop.* isn't really designed for plugin/theme testing and development and adding this and supporting it at this time might make it harder for us to make that possible.

#11 @MattyRob
10 years ago


I'm not sure that I understand your concerns but then perhaps I don't understand the issue fully.

Perhaps if this cannot be adopted into a core GruntFile.js script it could instead be viewed as a default file create in all new plugin repositories and available in the plugin / theme developers documentation such that files can be validated and minified using the same methods as the core WordPress files.

#12 @netweb
10 years ago

I knew I forgot to follow up something somewhere...

As I stated in #28464 :

1) This task will only run JSHint on plugins being developed in \src\wp-content\plugins

  • If a plugin developer needs, and I believe that they should, they should be running WordPress trunk from /build via the develop.svn repo or they should use core.svn to develop their plugin.
  • Developing plugins by loading WordPress via \src\wp-content\plugins of the develop.svn repo excludes RTL CSS or admin themes CSS (Midnight, Ocean etc) and I think we should be encouraging plugin authors to test their plugins for compatibility with these core features.

I should have included in that original statement that minified CSS and JavaScript files also do not exist (bar a handful of exceptions) in the /src folder of the develop. repo.

I am all for making available and utilising Core's Grunt tools to help plugin and theme authors, just at this stage adding what is outlined in this ticket in my opinion is clunky at best. Testing any theme or plugin in the /src folder without Core's minified CSS/JS is not testing we should be encouraging as utilising the SCRIPT_DEBUG constant in this use case with Uglify would not result in accurate nor reliable testing.

At this stage I still stand by that we should not be encouraging plugin/theme authors to develop their plugin/theme in the /src folder of the develop. repo whilst there are parts of WordPress Core that are non-existent in this folder.

I'd love to have workable solution that would allow this to be the case, where the developer develops in the /src folder and WordPress Core's Grunt tools can perform at least everything that the current Core tools can and copy/build everything into the /build folder where the developer has their WordPress install configured to run via the '/build` folder.

Plugin and theme authors should be using either core. SVN/Git repo or use a custom wp-content folder alongside the /build folder of the develop. SVN/Git repo.

#13 @dd32
10 years ago

Plugin and theme authors should be using either core. SVN/Git repo or use a custom wp-content folder alongside the /build folder of the develop. SVN/Git repo.

There's nothing wrong with using src for plugin development. Sure, they won't have RTL or minified styles, and won't have colour schemes, but that shouldn't impact upon most plugin development.
For testing, there's no question about it, if they're using the develop repo, they should then run grunt build to copy wp & the plugin to the build directory, where they can test those aspects of the plugin. That's an expected behaviour if they're using the develop repo.

That being said, I don't think core's grunt utils need to support plugin development, and that instead, we should maybe make available an example grunt-for-plugins Gruntfile.js for plugins usage, it'd encourage more plugin authors to take that route IMHO, customizing the Gruntfile as required for their plugin.

#14 @ocean90
10 years ago

  • Milestone changed from 4.1 to Future Release

#15 @johnbillion
10 years ago

  • Version trunk deleted

#16 @MattyRob
5 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

This ticket is no longer valid or important to me for several reasons:

1/ It's covered here:
2/ Core lack interest in it
3/ I'm no longer contributing to WordPress

As such I'm closing.

#17 @desrosj
5 years ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.