nss-run in 2018 (or what did change over the last 2 years)

Not so simple run (nss-run) is the logic evolution of complex build tools like grunt and gulp as well as minimalistic build tools like runjs.

What is nss-run

In a nut shell not so simple run (or in short nss-run) is a very simple build tool that is build around the premise to quickly create complex build files that mainly use plain Javascript or CLI tools. I wrote a first introduction at the end of 2016 which you can find here. But since then there has been a lot changes since I started using this for production ready applications. Lets look a bit into the current version and why certain things have changed since 2016.

Async by default

When I originally wrote nss-run all tasks ver synchronous. This helped making the API extremely simple and worked very well for 90% of all use-cases I had in mind for this tool. But when I started using it for some of my projects I run into issues where I had to use asynchronous JavaScript apis and ended up stranded with my simple build tool.

The first (and biggest change so far) was rewriting the complete plugin to make everything work async by default. To make the API a bit easier instead of relaying on callbacks it uses Promises for all async functionality. This has the second benefit that if you use modern NodeJS versions you can use the async/await pattern to make your nss-runfile even more readable and maintainable.

Even tho making everything Promise based to my surprise the API stayed extremely simple and most of my nss-runfile’s didn’t had to change a lot.

Adding documentation

One of the biggest flaws was always the lack of proper in-code documentation for the important API methods. I’ve documented everything in the project’s README. But when you where using more advanced editors like Webstorm you do not get the full power when modifying your nss-runfile. In addition to that I can now generate a simple documentation website to help you discover and explore the API faster. If you want to checkout the new documentation head over to github.

Answering questions

You might wonder what I mean by answering questions. During my latest use of the plugin I run into a unique (or maybe not so unique?) problem. I had a CLI tool that I needed to use which asked me questions. And there was no way to specify the answers for that questions as an argument. Further it was not just one question I had to specify multiple interactive answers which is not good for an automated build tool that should work without any user interactions.

To accommodate that the run command now has a new option called autoAnswer which allows you to scan the command output for certain texts. When that text appears nss-run will supply the specified answer to the commands stain. This works extremely well and solved a huge issue I run into for one of my projects.


As you can see there where quiet some significant changes based on real world experiences. Currently I am very happy with the build tool and will use it for more and more of my web projects. But as always I am happy for any feedback. Are you using it already or planning todo so? If yes what issues do you run into and would like to have solved with a simple solution? Let me know in the comments or create a ticket on github.


Florian Krauthan

Technology nerd, security advocate, writer and professional software developer