Add a grunt/build command

[mallorydxw]

I know "whippet theme grunt" exists, but that only runs grunt in one directory at once. Also, the "build" name may be more appropriate than "grunt" as we may want to support different tools in future (for us, or for other users of whippet).

whippet build start

This command will search for every Gruntfile.js in the whole application directory (ignoring node_modules and bower_components directories). Then in each of those directories it will start a docker container running "grunt watch".

whippet build stop

This will run docker stop on all the containers which belong to that application directory.

whippet build ps

This will show all instances of grunt, whether they're running, etc.

whippet build logs wp-content/themes/gds-blogs

This will show the stderr/stdout from the grunt command running in the gds-blogs theme.

We could also add a plain "whippet build" command which just runs "grunt" once without watching.

---

Typically we will want to use "whippet build" and "whippet server" simultaneously. Perhaps we should integrate this functionality into the "whippet server" set of commands? Or maybe add "whippet start" and "whippet stop" command that just runs "whippet server start/stop && whippet build start/stop"?

[harry-m]

I like this idea a lot.

It's definitely in the plan to integrate dxw/whippet-server into Whippet, and get rid of the separate project. I think that needs some thinking though. And some work. To make it Whippet-aware. Maybe?

PS: what docker stuff is pushed? Just feature/server? We should talk about how to dockerise this further, assuming we are going to do that, and update the readme with instructions. Should docker have some impact on how we're executing git commands? Do we need to do anything to ensure linux and macos compatibility?

[mallorydxw]

Yeah, just feature/server. I created a PR to discuss it in more detail at #14.

[dgmstuart]

@harry-m Integrate it into Whippet (maybe as a dependency?) yes, awesome. But remove it as a separate project? Why? Surely decoupling them is better.

If I'm hacking on a WP theme I'd want to be able to run whippet-server without subscribing to the whole whippet/whippet approach. Part of the awesomeness of whippet-server is how lightweight and unobtrusive it is.

Equally if I'm for some reason tied into developing with LAMP/MAMP, I should be able to get the benefits of managing my project with Whippet without being tied into one way of running my site (though I guess that's a given in any case, since a wp-content directory is the same shape however you manage it?).

Is it too much of a stretch to imagine that somewhere down the line there might be other things which implement the same interface as whippet-server, and that whippet users would want to be able to switch them out? I'm thinking about how rails by default uses Webrick as a server (which is part of Ruby core), but can be configured to use puma, unicorn, thin etc.

What kind of whippet-awareness would be useful? Could it be done by having the whippet server manage that awareness and control the stopping and starting of whippet-server?

[harry-m]

So there are a few things, but in a nutshell: I would like whippet server to run a whippet project from its app directory as though it had been deployed.

For example it would need to serve things from app/public, vendor directories in themes would not be accessible, .git directories in plugins also not accessible along with any tests in whippet-aware plugins. Things like that.

I like the idea of have swappable outable web servers a la rails but I think that's a future enhancement. Right now I want to be able to run a site when I'm devving with the safe assumption that it'll broadly work the same way as in a release.

[dgmstuart]

@harry-m TL;DR: that functionality should be part of Whippet, not Whippet Server

Thinking about how this works in Sinatra:

• By default assets are just served from the public directory
• If you want them to be served from somewhere else in development, then you add a gem which lets you configure in the app where they get served from
• This works by extending the routing of the app to cover the asset requests: instead of them just passing through and defaulting to looking in /public, it intercepts those requests and routes them elsewhere - e.g. to an /app/assets/ directory, or to a compiler.

This means the server can remain blissfully unaware of all that nonsense and work identically for local and production

[harry-m]

I'm not sure how we could do that given that WordPress's routing doesn't cover assets? And can't give us a mechanism to say "don't serve these files even though they are there"?

Also: how would the display of debug information work if the server is that basic? My understanding in Ruby apps is that the stuff you see on the development server is just the contents of stdout, and is generated by default in development. But Whippet needs lots of hooks and extra foobar to make that stuff work.

[dgmstuart]

I think the way that routing works in rails is via layers of Rack middleware, which modify incoming requests and (my guess is) log to stdout via the same logger as the application code.

Isn't whippet/whippet a wrapper around WordPress in the same way? Or have I gotten the wrong end of the stick?

The idea would be: the browser grabs the page, which contains an img tag src-ing from /images. When the browser requests /images we can intercept that request and redirect it to /assets/images. Is that just not feasible?

Alternatively it's always possible I just don't understand how websites work...

Sent from my iPhone

On 23 Mar 2015, at 10:00, Harry Metcalfe notifications@github.com wrote:

I'm not sure how we could do that given that WordPress's routing doesn't cover assets? And can't give us a mechanism to say "don't serve these files even though they are there"?

Also: how would the display of debug information work if the server is that basic? My understanding in Ruby apps is that the stuff you see on the development server is just the contents of stdout, and is generated by default in development. But Whippet needs lots of hooks and extra foobar to make that stuff work.

— Reply to this email directly or view it on GitHub.

[mallorydxw]

A common way to run WordPress is using Apache with mod_php. Apache serves the contents of a particular directory, and if test.jpg gets requested it just serves it with the appropriate mime type, and if index.php gets requested, mod_php runs that file through a php interpreter and serves the output. It's pretty much how CGI used to work, except now the interpreter is compiled into the Web server.

The way whippet-server works is that it uses php -S which basically does the same thing as I just described except it has no concurrency and it's harder to configure than Apache.

I recently made a change to the Dockerfile used in the feature/server branch (#14), and now it's using Apache and mod_php instead of whippet-server. So if we want to add support for serving files from the /public directory we just need to add a line to Apache's config.

[harry-m]

Hmm the whole point of whippet server was to get rid of the dependency on Apache, and ultimately, on MySQL as well ;)

I think finding a way to make it possible to package up any webserver you want to use is a good idea. But I don't think that's really got anything to do with whippet-server, it's a separate thing.

I guess this means we should integrate whippet server in in such a way as to allow you to use it, or something else, depending on your preference...

[mallorydxw]

Hmm the whole point of whippet server was to get rid of the dependency on Apache

Sure, when you run "whippet server start" you don't need to have Apache installed anywhere on your system. It all runs within the docker image. The main impetus for doing that was because whippet-server had some weird issue with nonces (wp_verify_nonce() was always returning false for no apparent reason).

I think finding a way to make it possible to package up any webserver you want to use is a good idea.

Yeah, in future it would be nice to be able to add other images to the docker-images/ directory. So when you run "whippet server start" you can just add a --image= option to specify "whippet-server" or "nginx" or "php7" or "hhvm".

[dgmstuart]

I think finding a way to make it possible to package up any webserver you want to use is a good idea.

Just in case we're not on the same page: yes that would be awesome, but it's not the main thing for me.

What I'm keen to keep is a standalone whippet-server, and my concern is that if it gets integrated directly into whippet/whippet then whippet-server will basically become unmaintained, since there probably won't be any benefit to dxw in back-porting improvements and fixes from whippet/whippet

[dgmstuart]

@harry-m @tomdxw looks like there's a <base> tag which can be appended to the head which sets the root for relative urls: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base

Could we hack this into the pages like they do in this live coding demo https://www.youtube.com/watch?v=5WuPFUoqxbI

[snim2]

The relationship between Whippet and our other systems has diverged since this discussion took place, however the original issue description is still current, and was also discussed in https://github.com/dxw/saluki/issues/60

We still want to build static assets, rather than shipping them with the theme. We cannot have a standard command that Whippet can run to do this (such as grunt run) because our themes are not consistent in their use of tooling.

Therefore, we should have a script in the scripts-to-rule-them-all pattern, which calls whichever tool is appropriate for the theme, e.g. script/build. Before script/build builds anything, it should install any necessary dependencies - that should be opaque to Whippet.

If scripts/build exists in the theme repo, Whippet should run it before deploy, and the deploy step should fail (or not be attempted?) if the build step fails.

Note that in our internal tooling, a separate Whippet command needs an upstream change which we might prefer to avoid, so ideally we would make this part of whippet deploy.

/cc @RobjS