Comments (8)
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.
Related Issues (20)
- Go Get Install Fails with fatal error: 'CoreServices/CoreServices.h' HOT 2
- Feature request: .htpasswd support HOT 1
- How to log request body? HOT 1
- Allow built-in livereload while stopping on SIGHUP
- Windows 10 and devd are not very friends
- Watcher not Working in Proxy Mode on Windows HOT 1
- devd doesn't listen if livewatch is specified HOT 5
- XDG support? HOT 1
- Markdown rendering HOT 3
- Compatiblity with future Go versions
- Can't serve a directory and watching a sub-directory
- `Origin` header doesn't seem to affect `Access-Control-Allow-Origin` response header HOT 2
- Be compatible with HTTP/2 HOT 1
- panic: runtime error: invalid memory address or nil pointer dereference HOT 2
- question: Is X-Forwarded-Proto set correctly? HOT 2
- linux 32 bit support HOT 2
- Out-of-date vendor dependencies are causing downstream builds to fail HOT 1
- Your connection is not private - Invalid cert for devd.io
- Feature request : log IP @ HOT 1
- [feature request] CLI option to add custom response headers HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from devd.