Improvements and new features?

[gpbl]

Hi @dmix,

thank you so much for this script! I'm evaluating Dust.js and it come very useful. So it may be I have yet to understand 100% how to use Dust in my workflow, but I'd like to contribute on it as new needs pop out, for example:

• make a packages.json and publish it an npm package
• make it available as command line tool
• improve console log's
• improve error management (no quit on errors)
• add command line options, e.g. to compile a single file [e.g. from Sublime Text]
• add tests

What do you think? What were your ideas for dusterjs?

[gpbl]

.. and also:

• remove the compiled dust when the source is deleted
• an option to compile all the dusts at start
• (maybe) use the relative path as template name. For example, shared/user/summary.dust could be named "shared/user/summary" instead of just "summary"

[dillongrove]

Bumping this thread to say that I agree with pretty much everything you listed. In particular, I would love to see this published on npm and usable is a package. In my particular case, I'm also already using Grunt to watch certain directories in my project and perform other tasks, so it would be useful to be able to run the script on a certain directory on command without watching, so I can let Grunt take care of the watching.

I'll likely end of implementing a few of these on my own fork for now. @BugBot -- do you know if the repo owner is still involved in the project? Doesn't seem like it from the lack of comments on issues...

[dmix]

I'm still involved although in the last few months I haven't been working on JS apps (where I can use dust.js templates) so I haven't iterated on this project recently.

I'd be happy to help out publishing an NPM and applying any merges.

[lee-houghton]

Bump.

I've done the following in my fork:

• Created package.json and published to npm (dusterjs)
• Made available as a command line tool using optimist
• Write to console when changes made (with --verbose option)
• Errors during compilation/writing output should be written to output, rather than crashing dusterjs.
• Compiles to one file by default (with a --no-concat option)
• Compress the result by default (maybe needs to pass better options to uglify though)
• Allow watching multiple directories
• Compiles all the dusts when started (no way to turn this off yet)
• Allow changing polling interval

Not done:

• Unit tests
• --quiet option
• Remove compiled JS when .dust deleted (though if you are not using --no-concat, you will be fine)
• Investigate using a directory watching method that is notified by the OS rather than polling
• Growl/etc. notifications (for errors).

It's significantly changed in both structure and code - I could create a pull request if you like.