A NodeJS-based tool for managing things every project needs, such as configuration, build scripts, assets, etc., using a flexible everything-is-an-asset approach, with configurable caching.

Project files define a project, its stones. Their content defines what commands are available.

Stones (named after whetstone) are individual building blocks of a project.

They represent a single logical asset (can be multiple files) or functionality (e.g. a dev web server). Stones can use other stones (via routes), to achieve their objective, forming a dependency tree. E.g. a css file could be made by minifying a file generated from scss source, and each step could be individually cached.

Stones try to keep all their state in a config object. Each stone requires it to be supplied. The config object should be designed for scripting, i.e. allow dynamic types as long as they make sense.

Reading and applying the configuration should be limited to generating resources/hashes from the stone. Invalid configuration therefore won't crash the project initialization until it's being used. This is just a guideline and not a requirement, and stones might validate the configuration immediately where it makes sense.

Some stones might provide helper methods to modify the configuration after it was passed in. Such methods might modify the config object, e.g. turning a single entry into array of them.

...

...

...

Project files should have no side effects, unless some of their commands are executed. They only process the active configuration, initializing the available commands.

All paths are in stored as absolute (starting with /), but are actually relative to root project directory. Path that is a directory ends with a /, otherwise it's considered a file. That means:

• /assets/ is a directory called assets that's in the project root.
• assets/ is a directory called assets that's relative to the structure within the project (routing/stones).
• /assets is a file called assets in the project root.