Trigger.io continuous development

Question

I'd like to know if there is any way to develop continuously with Trigger.io and avoid the forge build step with every file change I want to test in my browser or simulator.

Answer 1

I was faced with the same problem and I've got a working solution that uses watchr and watch to automatically rebuild each time I make a change to a source file. If you are running a "web" version of your app you can make a change to a source file and go directly to your browser and see the effect of your changes fairly quickly depending on how long the build takes.

Prerequisites: Ruby, watchr, Unix 'watch', and a terminal.

1. gem install watchr.
2. create a new ruby file for watchr to know what files to monitor and what to do when it sees a change. I named my file 'my_watch.rb': https://gist.github.com/3153167
3. open two terminals. Terminal 1 will run watchr and Terminal two will run 'forge build ...'.
4. In terminal 1 run 'watchr my_watch.rb' making sure the path to my_watch.rb is correct and make sure you've edited my_watch.rb according to your setup so that the path inside watch(...) reflects the files to be watched. My example watches all files in the same directory (and beneath) as the my_watch.rb script. You can place my_watch.rb in the 'src' folder of your Trigger.io app if you want to match my example and run watchr my_watch.rb directly from the src folder. Also not the shell command and path in the block need to be updated to reflect your environment. Again, in my example 'my_watch.rb' is inside 'src/' so when a change is detected we go up one directory and call 'forge build'.
5. I tend to develop actively with the 'web' version of my app so I can just open terminal 2 to my forge project directory and 'forge run web'. When I am testing in simulators and on devices, yes I have to run forge build every time I want to see a change. However, I typically don't have to wait for forge build to finish because watchr kicked off the build as soon as I made a change and it happens pretty quickly.

I know this is not an ideal solution but so far developing new features in the 'web' version first and then implementing in mobile versions has been very smooth for me. I've never needed to kill the 'web' version after a build but I maybe just lucky. As for running build each time you want to test the mobile versions if you are good with your keyboard shortcuts it really isn't bad at all. XCode makes you build and run after changes are made to source code when creating native iOS apps so I don't think Trigger is unique in requiring this build step.

I hope this helps and that my answer isn't too specific to me and my setup.

Answer 2

The build phase makes some changes to your source to enable the forge.* APIs - therefore, trying to just use the raw files in your src directory won't work.

You may be tempted to change files directly in the development directory, but this is a pretty bad idea: we delete those files with impunity when we need to!

We have plans on our medium-term roadmap to add a file-system watcher to start builds automatically when changes have occurred.

In the meantime, I just use forge build && forge run PLATFORM which tends to only take a few seconds...

Answer 3

while not perfect... this works for me.

go into development/web

rm src

link to your root src, ie ln -s ../../src src

copy the all.js from the web/forge and add to your index.html

ie

start nodemon web.js

open in browser.

note you will need to comment out the all.js script tag for non web builds.