Support build commands about devd HOT 8 CLOSED

This is something I want too, and I've been pondering how best to approach it. I've tuned up the file change monitoring in devd over the last week or so - it now copes with transient files, has a well-defined granularity (as opposed to just streaming a set of changes to the calling tool), and so forth. All of this would be very useful for change-triggerd build/run, so it seems like a no-brainer to make use of the same mechanism. Doubly so, since all the other build/run tools I looked at either take a naive approach, or require an interpreter like node (or both).

At this point, my plan is to make this a separate tool from devd - you can already see some signs of this in the codebase, as I'm isolating the livereload stuff in a module called "modd". This would be a sister project to devd, and designed to work well with it. Devd only does two things - serve static files, and act as a reverse proxy. So in the example you give, the src directory might be something like a Go daemon that needs to be built and restarted. The rough interface I have in mind for modd looks like this:

modd [-p prepare-cmd] cmd

Here, -p specifies a "prepare" step that runs and completes, and the cmd is a daemon that is kept running. If the prepare command fails, the daemon is not killed and keeps running. So you'd say something like this (presuming mydaemon takes a port to bind to):

modd -p "go install" "mydaemon 8080"

Now you can hack on your code, and when it compiles correctly, your daemon is restarted. At the same time, you can run devd like this:

devd -w ~/bin/mydaemon http://localhost:8080

The interface can be elaborated to cope with commands intended to run once and exit, which will let us cope with things like static resource builds.

This is a wee bit more elaborate than just rolling it all into one command, but I feel it's much more flexible, and frees modd up to be useful to people who might not be interested in devd itself. Thoughts?

from devd.

I'll second the "build" suggestion and suggest that you leave the functionality inside of devd. This is the tool that I like the design of the best. I do a bit of React development, however, and that requires building your react source (which is similar to building less or sass). For my own needs, I've got a ./build script setup to do all the heavy lifting. If devd could just launch a bash command whenever it detected changes, but before it triggered a reload, that would be awesome.

Running a separate modd command and devd command wouldn't be ideal because I would have two extra terminal windows open running services. That seems like extra work.

from devd.

@codazoda I'm actually tinkering with this now, and I'm beginning to agree that prep/build commands in devd itself would make sense. I'm going to make modd as well, because I need it and nothing else out there seems to work quite right.

from devd.

+1

Although I like the modd idea, I love how devd is such a powerful all-in-one tool. I'm already opening multiple windows to run the watch-and-compile programs, so I'd be super happy to replace those windows with an extra 20 chars on the devd command-line ;)

I tried a few syntax ideas for some simple use cases.

I'm wondering if a UNIX-style pipe idea could work, something like:

devd -l . --build "**.scss | sass $< $<..css"

The syntax is "ok" but not great. An improvement could be:

devd -l . --build "**.scss | sass"

but this relies on setting up rules for invoking sass somewhere, which could either be built into devd, in a file like $HOME/.devdrc or project-local in .devd. Still, it's getting close to duplicating a build system, and that doesn't seem like a good idea.

But if rules are set up somewhere, then the syntax could be simply:

devd -l . --build "**.scss"

To compile typescript as well I could add:

devd -l . --build "**.scss" --build "**.ts"

or

devd -l . -b "**.scss" -b "**.ts"

or maybe

devd -l . -b "**.{scss,ts}"

The expanded build commands, in my case:

build **.scss: 
    sass $< $<..css   # file-by-file

# OR directory with...
#    sass --update src/stylesheets:public/stylesheets

build **.ts:
    tsc -p src   # no filename args

Of course this is a bit simplistic with respect to dependencies within files, but for a one-liner, it'd be pretty powerful. Pros and cons!

from devd.

I think the simplest thing to start is the best way to go and then improvements can be made.

from devd.

After careful exploration of the issues involved, I've concluded that we can't do a good job of prep command execution within devd itself. The range of different behaviours needed to cover a reasonable percentage of use cases is just too large, and there are too many moving parts. That's the bad news.

The good news is that my cogitations have solidified into a good stab at the problem in modd. It can mange devd and trigger livereloads after prep commands have completed through a signal (see the -m flag to devd), so there's still only one command to run. The upside is that modd can do much, much more than that. I've had it working well for only a couple of days, but I already have a modd.conf file for every project I work on. It's gone from zero to an essential tool for me amazingly quickly. Unexpectedly, devd + modd has turned into a gulp killer for me - I've replaced 100+-line gulp configurations with small modd.conf files that are much simpler and more reliable (more on that anon).

Modd is not ready for a release yet, but I would love it if folks interested in this ticket would take a look at it, and give me feedback. There's a slew of small warts to fix, but the only remaining major feature in my initial plan is support for sending the output of failing commands to Growl and other notifiers. At the moment modd does not support Windows - I'd need to find a few days (or a skilled contributor) to make this happen.

from devd.

Great update! Will check out modd...

On 18 January 2016 at 17:49, Aldo Cortesi [email protected] wrote:

After careful exploration of the issues involved, I've concluded that we
can't do a good job of prep command execution within devd itself. The range
of different behaviours needed to cover a reasonable percentage of use
cases is just too large, and there are too many moving parts. That's the
bad news.

The good news is that my cogitations have solidified into a good stab at
the problem in modd https://github.com/cortesi/modd. It can mange devd
and trigger livereloads after prep commands have completed through a signal
(see the -m flag to devd), so there's still only one command to run. The
upside is that modd can do much, much more than that. I've had it working
well for only a couple of days, but I already have a modd.conf file for
every project I work on. It's gone from zero to an essential tool for me
amazingly quickly. Unexpectedly, devd + modd has turned into a gulp killer
for me - I've replaced 100+-line gulp configurations with small modd.conf
files that are much simpler and more reliable (more on that anon).

Modd is not ready for a release yet, but I would love it if folks
interested in this ticket would take a look at it, and give me feedback.
There's a slew of small warts to fix, but the only remaining major feature
in my initial plan is support for sending the output of failing commands to
Growl and other notifiers. At the moment modd does not support Windows -
I'd need to find a few days (or a skilled contributor) to make this happen.

—
Reply to this email directly or view it on GitHub
#18 (comment).

from devd.

I've just released modd v0.1. Please do check it out and let me know if you have any comments or feature requests.

from devd.