vladtsf / grunt-dust Goto Github PK

Apparently, grunt-dust uses

dust.compile(source, name)

to compile the templates -- the result of which registers the template under 'name' when evaluated.

However, I would like grunt-dust to compile my templates using

dust.compileFn(source)

that returns the compiled template itself, which is not registered under any name.

I may be totally missing something here, but downloading, npm install-ing and then running grunt test outputs:

Running "mochaTest:files" (mochaTest) task


  grunt-dust
    1) "before all" hook

  ✖ 1 of 9 tests failed:

  1) grunt-dust "before all" hook:
     Error: done() invoked with non-Error: 
      at /Users/alastair/Projects/git/grunt-dust/node_modules/grunt-mocha-test/node_modules/mocha/lib/runnable.js:198:38
      at /Users/alastair/Projects/git/grunt-dust/src/test/specs/dust_spec.coffee:12:11
      at ChildProcess.exithandler (child_process.js:636:7)
      at ChildProcess.EventEmitter.emit (events.js:98:17)
      at maybeClose (child_process.js:730:16)
      at Process.ChildProcess._handle.onexit (child_process.js:797:5)


Fatal error: ENOENT, no such file or directory '/Users/alastair/Projects/git/grunt-dust/src/tmp/dst'

If I make that /dst directory, it instead fails with:

Running "mochaTest:files" (mochaTest) task


  grunt-dust
    1) "before all" hook

  ✖ 1 of 9 tests failed:

  1) grunt-dust "before all" hook:
     Error: done() invoked with non-Error: 
      at /Users/alastair/Projects/git/grunt-dust/node_modules/grunt-mocha-test/node_modules/mocha/lib/runnable.js:198:38
      at /Users/alastair/Projects/git/grunt-dust/src/test/specs/dust_spec.coffee:12:11
      at ChildProcess.exithandler (child_process.js:636:7)
      at ChildProcess.EventEmitter.emit (events.js:98:17)
      at maybeClose (child_process.js:730:16)
      at Socket.<anonymous> (child_process.js:943:11)
      at Socket.EventEmitter.emit (events.js:95:17)
      at Pipe.close (net.js:451:12)

Fatal error: done() called multiple times

I also get an error when trying to use this as a grunt task in my main project.

I don't think the optimizers option is being passed through. I'm using it to preserve whitespace.

using

options: {
  optimizers: {
    format: function(ctx, node) { return node; }
  }
}

if you run grunt --verbose looks like its not being passed through

Options: runtime, basePath=false, useBaseName, relative=false, wrapper="commonjs", optimizers={}, wrapperOptions={"returning":"dust"}

Hi,

when i try to load 'grunt-dust' from the npm package i have an error that is generated at each template compilation :

timers.js:96
        if (!process.listeners('uncaughtException').length) throw e;
                                                                  ^
Error
    at /Users/mic0331/rep/webportal/node_modules/grunt/lib/util/task.js:47:25
    at Object.<anonymous> (/Users/mic0331/rep/webportal/node_modules/grunt/lib/util/task.js:390:1)
    at Module._compile (module.js:446:26)
    at Object..js (module.js:464:10)
    at Module.load (module.js:353:31)
    at Function._load (module.js:311:12)
    at Module.require (module.js:359:17)
    at require (module.js:375:17)
    at Object.<anonymous> (/Users/mic0331/rep/webportal/node_modules/grunt/lib/grunt/utils.js:17:14)
    at Module._compile (module.js:446:26)

Any idea ?

Thanks

Hi. I'm having a real issue with Dust trimming whitespace/linebreak.
This seems to be solved here
http://stackoverflow.com/questions/15769861/dust-js-include-partitial-without-trimming
by doing a

dust.optimizers.format = function(ctx, node) { return node };


What is your experience with dust? How do you solve this yourself?
What would be the easiest way of accessing grunt-dust and accessing dust, dust.comile or dust.optimizers? From reading the source code I don't dust beeing exposed anywhere. What would be a best practice?

Thanks.

Give users some way to modify the template name, similar to dustc name option:

dustc my_template.dust my_output.js --name="hi"

Dust offers the ability to debug things with dust.debug and dust.debugLEVEL

Hi,

As of Dust 2.5.0 you can set dust.config.whitespace = true to prevent whitespace from being stripped.

As of Dust 2.7.0, dust.optimizers is deprecated. It will be removed in a future release of Dust.

Hi there. Love the grunt task, just have a couple of requests.

I have a project which follows naming conventions similar to Ruby-on-Rails (e.g., myDustTemplate.js.dust). With the current implementation of grunt-dust, my [AMD-wrapped] templates would be created with module names as "myDustTemplate.js."

I was wondering if you might add a way to run a custom function from Gruntconfig right before inserting the final name in? That would give people the ability to do final processing on the module name. Looping through extensions would work too.

My second request is to add an option to return a renderFunction which accepts a callback to pass directly to dust. I love the idea of requiring a template and then using that required module to render instead of calling dust.render, but there are circumstances where you want to render asynchronously. Should be simple to check if a callback was given or not.

Let me know if you have any questions.

Thanks!

Resulting AMD paths from a relative/basePath configuration have mangled character escape sequences instead of proper '/' separated paths.

Example:

dust.register("controls\hideToolbarControl",body_0);

Hello,

i'm using your package to build the js files out of several dust templates.
I discover an issue when i try to add helpers's dust-linked-in functions inside my .dust template.

here is an example of a basic dust template :

{#current}
  {@select key ="{current}"}
    {@eq value="false"}
      <div data-id="{_id}" id="customer_item" class="content_prospect">
    {/eq}
    {@default}
      <div data-id="{_id}" id="content_prospect_green" class="content_prospect">
    {/default}
  {/select}  
{/current}

On the output I see nothing, the current variable is set to 'false' but the output is empty, the {#current} code block is by-passed.

do i make something wrong ?
Do you support "dustjs-helpers" and if not do you have any work-around ?

I'm posting this issue to let you know that we will be publishing Grunt 0.4 on Monday, February 18th.

If your plugin is not already Grunt 0.4 compatible, would you please consider updating it? For an overview of what's changed, please see our migration guide.

If you'd like to develop against the final version of Grunt before Monday, please specify "grunt": "0.4.0rc8" as a devDependency in your project. After Monday's release, you'll be able to use "grunt": "~0.4.0" to actually publish your plugin. If you depend on any plugins from the grunt-contrib series, please see our list of release candidates for compatible versions. All of these will be updated to final status when Grunt 0.4 is published.

Also, in an effort to reduce duplication of effort and fragmentation in the developer community, could you review the grunt-contrib series of plugins to see if any of your functionality overlaps significantly with them? Grunt-contrib is community maintained with 40+ contributors—we'd love to discuss any additions you'd like to make.

Finally, we're working on a new task format that doesn't depend on Grunt: it's called node-task. Once this is complete, there will be one more conversion, and then we'll never ask you to upgrade your plugins to support our changes again. Until that happens, thanks for bearing with us!

If you have any questions about how to proceed, please respond here, or join us in #grunt on irc.freenode.net.

Thanks, we really appreciate your work!

Loading "dust.js" tasks...ERROR
>> Error: Cannot find module '../src/tasks/dust'
>>   at Function.Module._resolveFilename (module.js:338:15)
>>   at Function.Module._load (module.js:280:25)
>>   at Module.require (module.js:364:17)
>>   at require (module.js:380:17)
>>   at Object.<anonymous> (D:\Repos\Project\node_modules\grunt-dust\tasks\dust.js:2:18)
>>   at Module._compile (module.js:456:26)
>>   at Object.Module._extensions..js (module.js:474:10)
>>   at Module.load (module.js:356:32)
>>   at Function.Module._load (module.js:312:12)
>>   at Module.require (module.js:364:17)
>>   at require (module.js:380:17)
>>   at loadTask (D:\Repos\Project\node_modules\grunt\lib\grunt\task.js:323:10)
>>   at D:\Repos\Project\node_modules\grunt\lib\grunt\task.js:361:7
>>   at Array.forEach (native)
>>   at loadTasks (D:\Repos\Project\node_modules\grunt\lib\grunt\task.js:360:11)
>>   at Task.task.loadNpmTasks (D:\Repos\Project\node_modules\grunt\lib\grunt\task.js:408:5)
>>   at Array.forEach (native)
>>   at module.exports (D:\Repos\Project\node_modules\load-grunt-tasks\load-grunt-tasks.js:27:29)
>>   at Object.module.exports (D:\Repos\Project\Gruntfile.js:38:32)
>>   at loadTask (D:\Repos\Project\node_modules\grunt\lib\grunt\task.js:325:10)
>>   at Task.task.init (D:\Repos\Project\node_modules\grunt\lib\grunt\task.js:437:5)
>>   at Object.grunt.tasks (D:\Repos\Project\node_modules\grunt\lib\grunt.js:120:8)
>>   at Object.module.exports [as cli] (D:\Repos\Project\node_modules\grunt\lib\grunt\cli.js:38:9)
>>   at Object.<anonymous> (C:\Users\user\AppData\Roaming\npm\node_modules\grunt-cli\bin\grunt:45:20)
>>   at Module._compile (module.js:456:26)
>>   at Object.Module._extensions..js (module.js:474:10)
>>   at Module.load (module.js:356:32)
>>   at Function.Module._load (module.js:312:12)
>>   at Function.Module.runMain (module.js:497:10)
>>   at startup (node.js:119:16)
>>   at node.js:902:3

Seems it doesn't like the coffee files, I'm running on Windows if it makes any difference

Hi,

first up: cool task, I like it.

I have two questions, though: I use the CommonJS wrapper and saw two things:

1.

module.exports = function() {
  var dust = require("dust-runtime");
  // ...
};

This fails when using with browserify. Is there a reason to not use a local path (require("./dust-runtime")). This seems to work (and should in node, too).

2.

module.exports = function() {
  var dust = require("dust-runtime");
  // ...
};

Why do you return the function instead of the actual dust object?

module.exports = (function() {
  var dust = require("dust-runtime");
  // ...
})();

Would make it more comfortable (not sure, if this is common in node, though).

Hi,

Thanks for using Dust!

> dust.compile("Hello {world}")
'(function(dust){function body_0(chk,ctx){return chk.w("Hello ").f(ctx.get(["world"], false),ctx,"h");}body_0.__dustBody=!0;return body_0}(dust));'
> dust.config.amd = true;
true
> dust.compile("Hello {world}")
'define(["dust.core"],function(dust){function body_0(chk,ctx){return chk.w("Hello ").f(ctx.get(["world"], false),ctx,"h");}body_0.__dustBody=!0;return body_0});'
> dust.config.amd = false; dust.config.cjs = true;
true
> dust.compile("Hello {world}")
'module.exports=function(dust){var tmpl=(function(dust){function body_0(chk,ctx){return chk.w("Hello ").f(ctx.get(["world"], false),ctx,"h");}body_0.__dustBody=!0;return body_0}(dust));var f=function load(ctx, cb) {\n      var fn = cb ? \'render\' : \'stream\';\n      return dust[fn](tmpl, ctx, cb);\n    };f.template=tmpl;return f}'

You may find it useful to delegate to Dust's native compiler to reduce your work.

(AMD support: Dust >= 2.6)
(CJS support: Dust >= 2.7)

It seems that in the examples given basePath produces the same output as if it wasn't included at all. The option also isn't in the source code.

This would be very useful to have, however....

hello,

is there a way to avoid the dust-core-1.1.1.js being recreated at each compilation in the destination directory ?

here is my config

dust: {
      dev: {
        src: 'public/js/app/views/templates/*.dust',
        dest: 'public/js/app/templates.combined.js',
        options: {
          amd: false
        }
      }
    }

the template is properly created, everything is going ok but i noticed that "dust-core-1.1.1.js" is added automatically in the same place as the "dest" option (so 'public/js/app/') or in my setup the lib is sitting in "public/js/libs/prod/dust/dust-core-1.1.1.js"

Thanks a lot.

grunt.registerHelper will be depreciated in grunt 0.4.

To see how helpers will be handled in the future (using standard npm require), check out the following links:

https://github.com/gruntjs/grunt-contrib-uglify/blob/master/tasks/uglify.js#L15 https://github.com/gruntjs/grunt-contrib-uglify/blob/master/tasks/lib/min.js

Currently I have a number of templates in my 'dust_templates' folder. I want them organized into sub-directories as follows:

dust_templates/partials/..
dust_templates/pages/..
dust_templates/base/..

I also want the template names to have the base name of the file in those folders (without sub folder paths). However the basepath option only allows users to exclude one of these paths not all. I recommend that there be another option called useBaseName that allows for this.

I managed tweak the code in the file dust.coffee (around line 77) and came up with the following snippet that does the job:

tplName =
if options.useBaseName
# use basename as template name
path.basename tplRelativePath, path.extname tplRelativePath
else
# remove extension from template name
tplRelativePath.replace new RegExp( "#{ path.extname tplRelativePath }$" ), ""

Could prove beneficial to someone else if it were a part of the main distro...

Is it possible to compile each template into an individual file? What is happening is that is joining each template in a folder into one file. I would like it for each template to be compiled into its own file.

Here is my current configuration:

files: [{
     expand: true,
     cwd: "target/build-prep/templates/",
     src: ["**/*.dust"],
     dest: "target/build-prep/templates/",
     ext: ".dust"
}],
options: {
     relative: true,
     wrapper: false,
     useBaseName: true
}

since i upgrade to grunt 0.4.0rc7 i have this error message when i launch the grunt command

$ grunt
Loading "dust.js" tasks...ERROR
>> TypeError: Object #<Object> has no method 'expandFiles'
Warning: Task "dust" not found. Use --force to continue.

Aborted due to warnings.

Any idea ? I'm running grunt-dest v0.2.0