Template processing in 1.0 breaks a grunt-ts feature

[nycdotnet]

Hi,

Shame on us for not testing grunt-ts with Grunt 1.0-rc1, but we've had a user report an issue with one of our features that works in Grunt 0.4.5 but fails with Grunt 1.0-rc1 and higher. It seems to be related to how lodash is now being used to process all items in the gruntfile for templates. We had been expecting to receive the template as a literal and then process it ourselves within grunt-ts for the htmlOutputTemplate task option. With 1.0, Grunt is trying to process the template prior to sending it to grunt-ts, and it's hitting a hard error.

There is a minimal repro here:
https://gist.github.com/gustavderdrache/a1e32d860b716dc4c10f88ebe62620a2

The relevant feature of grunt-ts is documented here:
https://github.com/TypeStrong/grunt-ts#htmloutputtemplate

The reported issue on our tracker:
TypeStrong/grunt-ts#357

We can recommend people start to escape their templates (such as I've recommended in our linked issue 357), but it would be nice to have a way to tell Grunt that our plugin expects a particular option to come-in unescaped or else to just not fail in the event that a template can't be processed. Thanks for your consideration.

[shama]

Interesting, I guess that worked in Grunt 0.4.5 because the task was relying on it ignoring template errors and you were grabbing the raw config? Unfortunately there isn't a nice way for tasks to override the lodash template delimiter for just the task.

A user can override the delimiter for the entire config by adding the following to their Gruntfile: grunt.template.addDelimiters('config', '{%', '%}'); but this means all templates in their Gruntfile will need to be switched from <%= %> to {%= %}.

A better option, IMO, is have the htmlOutputTemplate option use another delimiter instead and avoid the conflict completely. Then the grunt-ts task could likely start using the Grunt API and avoid having to parse the config itself.

Down the road, tasks will likely be able to configure more specifically how the config is read but atm, there isn't an API for it on the task level.

[shama]

Actually, it looks like the behavior is still possible:

module.exports = function(grunt) {
  grunt.initConfig({
    test: {
      options: {
        template: 'What <%= ya %>'
      },
      gruntfile: {
        src: 'Gruntfile.js'
      }
    }
  });
  grunt.registerMultiTask('test', function () {
    console.log(grunt.config.getRaw(['test', 'options']));
  });
};

will work because it avoids calling any API that will parse the Grunt config. So you might still be able to use that behavior if you avoid calling anything that parses the config.

Although I still recommend just using another delimiter to avoid the conflict.

[nycdotnet]

Yes, grunt-ts does a LOT of work messing around with the raw config - likely too much. I am not sure this bug merits mucking around with that code.

Using another delimiter for the HTML features is an interesting idea. I'll have to think about the merits of that versus just recommending that people escape the templates for the HTML feature.

It sounds like this is not an actionable ticket for you. Thank you for the ideas!

[shama]

FWIW, at my work we are switching to use grunt-ts so hopefully in time I can help out as soon as I get more acquainted with the project.

[nycdotnet]

Oh awesome. I'd love the help. :-)