grunt uglify for plugins and plugin developers

[MattyRob]

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.

[nacin]

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

[MattyRob]

Is v2 patch better?

[nacin]

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

[MattyRob]

More like the v3 patch then?

[MattyRob]

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.

[GaryJ]

Little typo in the patch: requite => require.

[MattyRob]

v5 patch fixes reported typo.

[jorbin]

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.*.wordpress.org 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.

[MattyRob]

@jorbin,

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.

[netweb]

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.

[dd32]

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.

[MattyRob]

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

1/ It's covered here: ​https://developer.wordpress.org/cli/commands/scaffold/plugin/
2/ Core lack interest in it
3/ I'm no longer contributing to WordPress

As such I'm closing.