Add task runner to automate build/deployment

[stephenharris]

I'm proposing we add a task runner to automate deployment to .org repo.

In essence it would make this repo a development repo rather than a production one. However, because there are no javsacript files or CSS to compress, or any other files to be 'built' when going from development --> production, in practise it just means adding two files: package.json and Gruntfile.js (which one wouldn't normally expect, or need, when using it in production).

The other difference is that the assets directory would no longer appear in the .org version, but instead me committed to the assets directory on the .org repo.

[franz-josef-kaiser]

The other difference is that the assets directory would no longer appear in the .org version, but instead me committed to the assets directory on the .org repo.

Could you elaborate?

Aside from that, I'd say we could need the Gruntfile for minification: The dashicon stuff should go into a stylesheet and that one should be, depending on constants/flags be available in compressed/uncompressed versions.

[stephenharris]

Yup, so I have been just committing the whole directory into the SVN trunk and tag/<tag> directories, and then also committing the assets to the assets SVN directory. (This essentially means that assets is committed three times).

As far as I can tell, there is no need for it to be committed to trunk or tag/* - the end user doesn't use any of the assets in that folder (it's only there for .org, which uses the assets SVN directory).

As part of automating deployment to .org it's possible to exclude the assets directory, but mark it to be committed to the SVN assets directory. This means if you download a zip from GitHub, it would contain the assets directory, but it wouldn't if you download it from .org. (Similarly it would be possible to exclude .gitignore which is included in the .org download, although it isn't needed.

[franz-josef-kaiser]

:+1:

[stephenharris]

Aside from that, I'd say we could need the Gruntfile for minification:

If so, that would lead to more differences between GitHub and .org. I don't version control minified files, so they wouldn't appear on GitHub, but they would be included in the .org version.

[franz-josef-kaiser]

Well, we could make use of a package.json part called scripts (or use the ones from composer.json):

"scripts" : { "postinstall" : "minify assets/main.css > assets/main.min.css" } }

or similar. This is what I'm currently using when a project still is small enough and I have no need to pull in a full Gruntfile.js. We could as well simply use a .git/hooks/postinstall hook and leverage the minification from there. Personally, I'd prefer to have it running from composer.json as this is how I install plugins. Everyone just downloading it would have an unminified file, but I could life with that.