Idea: Create a separate "build" step, so that Meteor users don't have to rebuild the app to run 'vagrant-spk dev'

[paulproteus]

This seemingly would also help @mnutt with a nodejs app.

[zarvox]

Tricky. Just the other day, you wanted to merge the init and dev and pack steps as much as possible. :P

I wonder if we should split the "I want to iterate on my Sandstorm app" from "I think my source changes are done, let's package this up." Many packages have a "fast iteration" workflow and a "minify everything and get all the performance optimizations possible" workflow. For compiled languages, there's even compiling with or without optimization passes.

Maybe the verbs we want are:

• vagrant-spk build - runs build.sh
• vagrant-spk dev - same as what it does today (runs build.sh and then adds to server's devpackages)
• vagrant-spk trace - same as vagrant-spk dev, but without first running build.sh (except that the likely users of this mode are the ones that don't need tracing, hmm.)

This way we don't break backwards compatibility for devs.

[zarvox]

Yeah, trace is not a great name, but I think the idea might have merit.

[mnutt]

Copy-and-pasting from my email for posterity:

I also wonder if this would also be helpful with building assets? Davros has an Ember frontend, and by default it uses unminimized assets with debugging enabled. Then when you ember build --production you get minimized, stripped assets. Right now it’s not a huge pain point to just swap out steps in build.sh but it might be cool to have a process to do it.

I like the "iterate" vs "build". I'm not sure whether or not there's value in having a "build the app in production then run it step", I'd be fine just packing it and testing it at that point but I could see how someone could want it.

[paulproteus]

A similar consideration:

To many web app authors, dev and prod are meaningful terms. So maybe that suggests these verbs:

• run-dev
• run-prod
• pack

Their specific meaning, I'm less sure of!