[Feature] Hooks feedback & activation on individual files

[robstown]

Quick, short summary:
First of all, I have to say that hooks were awesome in CK2 and are even more useful in CK3. Being able to process any file type (an thus trigger a hook) helps a lot. For example, I have a transpiler I made to make useful JSON files out of XML schema files I have no control over. I used to have to change the .xml extensions and process it as another type of file in CK2. It's nice to work with the file natively now. Two minor suggested enhancements for how Hooks work:

1. Pipe bash/terminal feedback to a codekit screen. Right now, if you have a bug in a hook script, you have no feedback what is causing an error. I am not a bash expert, or even a good speller, so I make a lot of mistakes. It would be nice to have the option to see what you might otherwise see in a terminal window after executing commands so it is easier to debug and see status. I understand that hooks can't be interactive, but a little feedback would help.

2. Trigger hooks on specific files in the files tab. Currently, you determine when a hook is triggered using the series of pull down options (name/path->matches/contains/end in/etc) in the settings -> hooks tab. If you want to process a specific file or set of files, you have to make sure you use a set of descriptors that match the file(s) you want and not others you don't want to trigger the hook. This requires naming conventions and coordination between the rules and files. It can also become brittle when names and paths change. It would be nice to have another option in the files tab "when this file changes or builds, activate hook". This will allow you to easily apply the hook to a file, change the filename, process other files, and not have to constantly coordinate descriptors.

Good stuff in CK3!!

Expected results:
Ability to see bash/terminal results of running hooks. Ability to apply hooks to individual files.

Actual results:
No terminal feedback. Use a series of file/path descriptors to trigger hooks.

Exact steps to reproduce:

A link to download a simplified project or file that shows the issue:

Your configuration (any details about your system that you think might be relevant)
Codekit 3.0 build 23903

[subhaze]

This is a... workaround?... if you will, but I'll trigger notifications via osascript a lot to keep my sanity on if I've coded things correctly in hooks, such as correct criteria and/or error capturing.

To capture errors, push the stderr to the stdout, then use good o'l /dev/null:

err="$(ehco 'blah' 2>&1 1>/dev/null)"
if [ -n "$err" ]; then
    osascript -e "display notification \"$err\" with title \"Hook Script Error\""
fi

The above I've typo'd echo and it'll get a notification alert that states the line number of error and command that caused it.

And if you want validation on both err and success you could else it via:

err="$(echo 'blah' 2>&1 1>/dev/null)"
if [ -n "$err" ]; then
  osascript -e "display notification \"$err\" with title \"Hook Script Error\""
else
  osascript -e "display notification \"SUCCESS! My code ain't broke!!\" with title \"Woot!\""
fi

[bdkjones]

Implemented for Beta 2. Here's how it works:

For Bash Hooks:

You will see messages in the Log when any of these circumstances are met:

1. Your Hook throws an exception. Previously, CodeKit would just crash. In the future, CodeKit may still crash if your script is just so janked that the app can't recover. But for simple exceptions, such as a launch path not being accessible, you should now receive a message in the log. Note: if anyone can come up with a script that throws an exception to test this, that would be great.
2. Your Hook returns a non-zero exit value. If your Hook does this, it is expected that you've written something to StdErr. If you have, you'll see it in the Log. If you have not, then you'll see a message in the log telling you that Hook X returned a non-zero value but didn't log anything to StdErr.
3. Your Hook returns a zero exit code and writes anything to StdOut You'll see whatever is written to StdOut in CodeKit's log.

Note:

If it's amateur hour and you return 0 but write output to StdErr (here's looking at you, TypeScript!), that won't be logged. Likewise, if you return non-zero but write to StdOut, that won't be logged either. Program correctly. The error level of the logged message will be regular (green) for StdOut messages and error (red) for StdErr messages.

For AppleScript Hooks:

There is a new API in the scripting dictionary for Beta 2. You can use this to log any message with any error level (regular, warning, or "problem" --- because error is a reserved word in AppleScript).

[bdkjones]

I should also mention an important implementation detail. Suppose you highlight 5 files in CodeKit and click Process All. Each of these files meets the criteria to trigger a given Hook.

The way CodeKit works, all five of these files will be processed using the settings you've specified in the app (syntax check, transpile, minify, etc.) BEFORE any Hooks are run. That is, the Hook is run at the end of the group of files being processed, not after each individual file is processed.

When the build process is complete, this will still apply. During a build, files will be "grouped" based on their dependencies. If File X imports the output of File A, then A will compile in one "flight" or "group" and then when that group is finished, X will compile in a second group. Hooks will be run at the end of each "flight" or group.

This is basically for performance reasons.

[subhaze]

Nice! I'll try to give this a go on next release! Great addition.