Nift has support to optionally run pre/post build scripts/programs when building a website. 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.. Use any scripting or programming language, eg. batch, bash shell, C/C++, C#, fish, go, Haskell, Java, Javascript, Objective-C, Perl, PHP, Python, Ruby, Swift, Zsh shell.

Note: Make sure all 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 .nift/config.json configuration file, which may be checked 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 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, the site configuration file .nift/config.json can optionally include backupScripts bool to indicate whether build scripts/programs should be backed up when run.

Alternatively one can write scripts/programs that are run manually (not using Nift) which themselves add the Nift build process, leaving just one program that needs to be run when building.

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


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:


Note: Running lots of page-specific pre/post build scripts/programs does not scale well to hundreds of thousands of scripts/programs. If 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 scripts/programs as it will mess up the other threads that are also running scripts/programs and/or building pages. If one really must change directories in scripts/programs then 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 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 faster build times.