No more Grunt!

As part of the push towards Ghost 1.0.0, and getting rid of things which get in our way, we’re going to look towards getting rid of Grunt. The tools we have now were first created before we split the admin client out of the main repository. The current versions are designed to match how the old tooling worked, but with the new setup.

They work but are slow, hard to use and confusing. Some tools are for installing, some tools are for developing and some tools are for releasing. The tooling isn’t really good at one particular job.

The goals for the new tooling are:

1. An amazing set of developer tools that make it really easy for people to contribute and for us to do our jobs.
2. A very separate set of “install” tools. From Ghost 1.0, installing is going to be handled by the Ghost CLI tool. We’re going to be recommending this for all production installs, and discouraging installing from git for production.
3. A single command for the purpose of converting source code to a ready-to-run build.
4. A release script which does ALL THE WORK and makes releasing super-crazy easy.

Installing from git will be for those people developing Ghost, so the tools we have in the repository should be geared towards making it super easy to develop.

In Ghost-Admin, I don’t think we need much on top of ember-cli itself.

• what to do about the buildAboutPage task?
• can we run csscomb without Grunt/Gulp?

In Ghost, I want to remove the release-specific tools, and focus on having an amazing set of tools for contributors. I recommend that we use Gulp rather than Grunt, as it’s much faster, and setup any npm aliases that are common amongst dependencies (like npm test).

• New dev task that supports both client & server watch & livereload
• Tools for watching just client or server?
• Setup tool, for initialising the different repos on a particular PR/commit?
• Test tools
• Coverage tools
• Linting tools

Aside from the development tools, which will do watching & live reloading, we should have one single command which will ensure the state of the source code (sync the submodules), do all build tasks to convert source code into built code, and also provide an opportunity for any minification or optimisations needed for production. I think this will likely be a gulp build command, aliased to npm run build.

• gulp build task

All release-specific code (handling npm dependencies, version bumping, generating contributor lists (except for the ones needed for the about page), zipping, etc will live in a separate place (although will probably also be built with Gulp).

• remove release-related code

[kevinansfield]

WRT csscomb, I think having it as part of the gulp tooling is probably the best first step, then we can look at making a broccoli plugin that runs it as part of the ember-cli build process later on.

[ErisDS]

Labeled with later & closing for now.