Do not recompile unnecessarily

[notramo]

Compilation takes long time on lower end devices.
lucky recompiles the app every time it runs a task. It's sometimes necessary, but there are many cases where it's not, because the code haven't changed.

For example, when I write a migration, I always test the rollback feature at least 2 times (migrate - rollback - migrate - rollback - migrate). In this case, if there are no errors, recompilation would be unnecessary.
Another case is editing a file that doesn't affect Crystal code, e.g. credentials in .env. When the developer edits e.g. a password, and restarts the app, recompilation is not necessary.
Another use case is when the developer runs lucky gen.* commands, but mistype the name.
Another example is the --help command.

Tracking changed code is complicated, and there could be many factors that would influence compilation outcome (e.g. compile-time values in ENV vars which are read by macros), so the simplest solution would be to leave it to the user to know if they made changes or not.

I suggest adding a switch (e.g. -n, --no-recompile), which would enable lucky to use the latest compiled binary.
lucky db.migrate - recompiles, and runs
lucky -n db.migrate - runs the latest compiled version again

[jwoertink]

You can actually just compile these if you need.

crystal build tasks.cr -o bin/tasks
./bin/tasks db.migrate

That will compile all of our tasks and allow you to use the ones you don't want to recompile each time but still give you the escape of using lucky db.migrate to recompile when you need.

I think when the interpreter is default in Crystal, those tasks will actually just run in interpreted mode by default to reduce runtime and we'd just add a flag to tell it to compile and store the binary and run.

# runs interpreted
lucky db.migrate

# compiles, then runs compiled
lucky db.migrate --compile

# runs the compiled version because the binary exists
# but also prints a notice that it's running the compiled binary
lucky db.migrate

I haven't put a ton of thought in to it since the interpreter is still a bit away.

[notramo]

Until the interpreter matures, the compilation switch could be implemented.

I would recommend enabling it by default, and explicitly disabling it (--no-compile) instead of explicitly enabling it with --compile, because if the user accidentally forgets to specify the switch, a little extra compilation causes less harm than running an old version of the code.