Closed navneetgarg123 closed 7 years ago
I like the idea of being able to run context-specific tasks, but it seems like there is a ton of overlap between this proposal, and Jake namespaces:
http://jakejs.com/docs#tasks_namespaces
How is this different from namespaces?
The use case I found it useful would be with development/production environments.
I want to use jake
as my entry point build tool/task runner for everything regardless of environment. I'd rather not even have my test
namespace exist or load when in a production or staging environment because that's going to use dependencies that aren't installed (and error out as a result).
maybe environment
would make more sense than group
. I was envisioning something like
environment('production', function () {
// require non-dev dependencies
desc('start production server');
task('start', function () {
// start production server
});
});
environment(['development', 'test'], function () {
// require development/test deps
namespace('test', function () {
// test related tasks
});
});
The issue with namespaces is that the namespaces (and tasks for that matter) get loaded no matter what - which prevents me from using jake
in production.
Rather than trying to add this as a feature into the framework (given how similar it is conceptually to namespaces), it might make more sense to make use of the fact that Jake is really just all executable Javascript. A Jakefile is simply pulled into the runtime via ordinary require
-- you could easily accomplish what you're wanting via an environment-specific require
in your Jakefile:
'use strict';
let env = process.env.NODE_ENV;
if (env) {
require('./' + env + '_jakefile.js');
}
else {
console.log('Please set NODE_ENV');
}
Just run it something like NODE_ENV=production jake -T
(You would need a production_jakefile.js file in the directory where you run the command.)
That implementation works if you put your tasks directly in the Jakefile, however it becomes slightly more unwieldy if you utilize the jakelib
directory to split out the tasks.
It's definitely possible to setup the requiring of the subsequent jakefile and the necessary directory/directories but I guess I was considering more of a convention to do the environment specific requiring.
It's starting to look like the environment
function might be something that could live external to jake actually.
Right, the jakelib approach eagerly does a require
of everything in that directory. Yes, just wrapping the lazy require in a library might be the optimal approach here. Shall I go ahead and close this issue?
Yes please. Sorry I thought I'd responded to this already.
Allow for environment specific task loading
define a
group
function that that takesgroup
is specified for a namespace or task, assume it is in thedefault
groupNODE_ENV
or by a command line option.Example Usage:
Inspired by ruby - Bundler/Rake