I have what is frankly a somewhat bizarre workflow for my current project at work. We have a self-hosting .Net component, that does a bunch of stuff. Very impressive, but not what I want to talk about right now.
I’m beginning work on the html client for this piece of software, and because my employers are awesome and have invested in a couple different training programs for me I have a whole slew of modern client-side development tools available at my disposal. They’re awesome, they do their jobs, work consistently, and (for the most part) are a relative breeze to use.
But there isn’t really a clear-cut workflow for dealing with Visual Studio’s monolithic (and highly useful) build system.
Hello Gulp
Since I’m not doing a single ounce of backend programming for this project, I’ve chosen to create a build pipeline via the gulp task runner. It has all the tools I need, and it was a good excuse to play around with it having already dipped my toes into grunt‘s waters. Everything was going fine and dandy until I edited my project’s Post-Build event to look something like this:
set guplexec=gulp
IF "$(ConfigurationName)"=="Debug" set gulpexec=gulp dev
%gulpexec%
rmdir /S "$(TargetDir)Content\"
xcopy "$(ProjectDir)Content\*" "$(TargetDir)Content\" /E /I /Y
I’m sure you can imagine my surprise when gulp executed flawlessly and then nothing else ran. The post-build script then went through a few revisions with varying levels of love, finally arriving at the magic keyword that makes it behave: call.
For some reason, the command call %gulpexec% executes and then will properly resume the rest of the script (yes it also works when written as call gulp and call gulp dev if you’re wondering). I would imagine it’s some kind of weirdness in whatever shell script is inserted into the PATH that triggers the gulp build pipeline running on node.js. I could be entirely mistaken in the supposition, but I’m just happy to have found a nice little workaround.