Scripts/Programs

## Pre/Post Build/Serve Scripts/Programs

Nift has support for you to optionally add in pre/post build/serve scripts/programs to your websites. Just a few of the things this can be useful for includes integrating with webpack, Babel, npm, Bower, Yeoman, Browserify, Parcel, Brunch, SASS, Grunt, Puppeteer, Python webserver, Live Server, Live Reload, etc.. You can use any scripting or programming language you want, eg. batch, bash shell, C/C++, C#, fish, go, Haskell, Java, Javascript, Objective-C, Perl, PHP, Python, Ruby, Swift, Zsh shell and many more.

Note: Make sure your scripts/programs have executable permissions, otherwise Nift will be unable to run them and should throw a build error.

The script extension for website-wide scripts/programs is specified with scriptExt in the .nsm/nift.config configuration file, which you can check using the Nift command config. To check page-specific script extensions use the Nift command info page-name. Site wide and page-specific script extensions may be set using the Nift command new-script-ext (page-name) script-extension.

Note: Build/serve scripts/programs are moved to the project root directory to run and by default have a backup copy made. If scripts/programs are so large that copying the file will take time, your site configuration file .nsm/nift.config can optionally include backupScripts bool to indicate whether build/serve scripts/programs should be backed up when run.

Alternatively you can write scripts/programs that you run yourself (not using Nift) which they themselves add the Nift build process in to them, leaving you with just one program that you need to run when building. You will still get to take advantage of Nift's unbeaten build times and powerful template language doing this.

Note: Scripts/programs are run from the project root directory, so all paths in scripts/programs should be starting from that location. Also do not change directory in your scripts/programs as it will mess up the other threads that are also running scripts/programs and/or building pages. If you really must change directories in your scripts/programs then you will have to set the number of build threads to 1 and change back to the project root directory before each script/program ends. Furthermore the output of scripts/programs is not displayed to you when building until after they have finished running, so there is no way to display messages to the user if using user input methods and so are discouraged from being used (plus you would have interference output from other threads), a compromise for much much faster build times (user input is not how you want to be building websites anyway).

Website-wide scripts/programs should reside in the project root directory in a file to be named as follows:

pre-build.scriptExt
post-build.scriptExt
pre-serve.scriptExt
post-serve.scriptExt

It should be reasonably self-explanatory what each will do, though note the pre-build and post-build scripts/programs are run before or after each of the Nift commands build, build-all, build-updated.

Page specific scripts/programs should reside in the same directory as the content file for the page in a file to be named as follows:

pagename-pre-build.scriptExt
pagename-post-build.scriptExt

Note: Running lots of page-specific pre/post build scripts/programs does not scale well to hundreds of thousands of scripts/programs. If you are working on projects that large you might have more luck calling one site-wide build script/program with multithreading.

Note: Scripts/programs are run from the project root directory, so all paths in scripts/programs should be starting from that location. Also do not change directory in your scripts/programs as it will mess up the other threads that are also running scripts/programs and/or building pages. If you really must change directories in your scripts/programs then you will have to set the number of build threads to 1 and change back to the project root directory before each script/program ends. Furthermore the output of scripts/programs is not displayed to you when building until after they have finished running, so there is no way to display messages to the user if using user input methods and so are discouraged from being used (plus you would have interference output from other threads), a compromise for much much faster build times (user input is not how you want to be building websites anyway).