javascript - Grunt task grunt.option set by previous task returns undefined -

i'm running number of grunt tasks on project. 1 of sets number of grunt.options grunt.option(key, value) need access in subsequent task var option = grunt.option(key). these options returning undefined when try access them in latter task.

if log variable @ head of latter task, shown before task run , unable access set value in tasks config.

is there need between setting grunt.option , using in task notify grunt of change? doing inherently wrong here? or there better way global variable of sorts (my research pointed me using grunt.option)

my gruntfile.js

grunt.log.writeln('loading tasks'); grunt.loadtasks('grunttasks'); grunt.log.writeln('tasks loaded');  grunt.registertask(     'jenkins',[         'clean', //clears out existing build folders         'curl', //gets build config file remote server         'set-env', //sets grunt.options based on build config file         'string-replace:config', //attempts access new grunt.options         ....         ....         ....         ....     ] ); 

in set-env task, set environment variables based on contents of text file returned in curl task. works fine , can log grunt.options after setting them know being set correctly.

set-env-task

module.exports = function(grunt) {      grunt.registertask('set-env', 'set-env', function() {         ......         ......         (var = 0; < propfile.length; i++) {             if (propfile[i] !== '') {                 ......                 ......                 keyvalues[propname] = propvalue;                 grunt.option(propname, propvalue);                 console.log("from grunt.option " + grunt.option(propname));                 ......                 ......             }         }         ......         ......     });  }; 

when try , access grunt.options set in above task string-replace (or other subsequent) task undefined returned. if set test values these grunt.options @ start of gruntfile.js can access them no issue:

module.exports = function(grunt) {     grunt.config('string-replace', {         ..........         ..........         config:{             files: configfiles,             options: {                 replacements: [                     ..........                     ..........                     {                         pattern: /var _option_key = \"(.*?)\"\;/ig,                         replacement: 'var _option_key = "'+grunt.option('_option_key')+'";' //grunt.option('_option_key') here undefined                     }                     ..........                     ..........                 ]             }         }         ..........         ..........     });     grunt.loadnpmtasks('grunt-string-replace'); } 

(i have double, triple , quadruple checked i'm using correct option keys)

the problem you're accessing variables grunt option set during "config stage" of task, runs 1 time, before set options in set-env task. evaluating custom option key @ point in code indeed should yield undefined. (note practically equivalent of using initconfig block)

what instead instead of reading option values options object, modify config object of task directly, using grunt.config.set, enable you've been trying.

so basically, instead of

grunt.option(propname, propvalue); 

use like

grunt.config.set('mytask.replacements', options.replacements); 

(of course, require sizable reworking of code, don't that.)

---

edit: there's cleaner solution using templating functionality of grunt, see this stackoverflow answer, , grunt api docs on templating:

template strings can processed manually using provided template functions. in addition, config.get method (used many tasks) automatically expands <% %> style template strings specified config data inside gruntfile.

the point being these evaluated not when config block parsed, when task reads values using config.get.

---

your pattern of using options object share values between tasks works better if it's between 2 custom tasks of yours - can set in 1 task, read in other, not in configuration, actual step of running tasks.

in general, although seems doable, i'd not workflow grunt has in mind - if know environment you're running grunt in, it's easier pass in environment parameters through options command-line flag directly when run grunt task, take effect in task configuration you're doing.