grunt configure settings file dynamically - javascript

I have two files that get loaded, shown below. I want to dynamically load the settings file by name in properties.js. I want to replace <%= settings["build.target.environment"] %> with the value from the environment build option. Whenever i try to replace the value i get a compilation error in grunt. Basically, cant load tasks, X task isnt found because no tasks loaded properly. I have an alias called init that runs both of these items in order. How can i get the build option into the properties file so i can dynamically load the config i want to load. or is there another option? It seems like my build option wouldnt be picked up at the time these files load.
please bear with me and any ignorances with grunt, relatively new to grunt.
properties.js:
module.exports = {
settings: 'config/build.properties',
instance: 'config/environment.<%= settings["build.target.environment"] %>.properties'
}
buildoptions.js:
module.exports = function(grunt) {
grunt.registerTask('buildoptions', 'set build version and repo branch', function() {
var build = grunt.option("build");
var branch = grunt.option("branch") || '';
var environment = grunt.option("environment");
grunt.config('build', build);
grunt.config('branch', branch);
grunt.config('environment', environment)
});
};
aliases.json:
"init": [
"buildoptions",
"properties"
]

You don't need to set local variables to access grunt.option values within template strings, instead reference it directly:
module.exports = {
settings: 'config/build.properties',
instance: "config/environment.<%= grunt.option('environment') %>.properties"
}

Related

Application modularity with Vue.js and local NPM packages

I'm trying to build a modular application in Vue via the vue-cli-service. The main app and the modules are separated projects living in different folders, the structure is something like this:
-- app/package.json
/src/**
-- module1/package.json
/src**
-- module2/package.json
/src**
The idea is to have the Vue app completely agnostic about the application modules that can be there at runtime, the modules themself are compiled with vue-cli-service build --target lib in a local moduleX/dist folder, pointed with the package.json "main" and "files" nodes.
My first idea (now just for development speed purposes) was to add the modules as local NPM packages to the app, building them with a watcher and serving the app with a watcher itself, so that any change to the depending modules would (I think) be distributed automatically to the main app.
So the package.json of the app contains dependencies like:
...
"module1": "file:../module1",
"module2": "file:../module2",
...
This dependencies are mean to be removed at any time, or in general be composed as we need, the app sould just be recompiled and everything should work.
I'm trying to understand now how to dynamically load and activate the modules in the application, as I cannot use the dynamic import like this:
import(/* webpackMode: "eager" */ `module1`).then(src => {
src.default.boot();
resolve();
});
Because basically I don't know the 'module1', 'module2', etc...
In an OOP world I would just use dependency injection retrieving classes implementing a specific interface, but in JS/TS I'm not sure it is viable.
There's a way to accomplish this?
Juggling with package.json doesn't sound like a good idea to me - doesn't scale. What I would do:
Keep all available "modules" in package.json
Create separate js file (or own prop inside package.json) with all available configurations (for different clients for example)
module.exports = {
'default': ['module1', 'module2', 'module3'],
'clientA': ['module1', 'module2', 'module4'],
'clientB': ['module2', 'module3', 'module4']
}
tap into VueCLI build process - best example I found is here and create js file which will run before each build (or "serve") and using simple template (for example lodash) generate new js file which will boot configured modules based on the value of some ENV variable. See following (pseudo)code (remember this runs inside node during build):
const fs = require('fs')
const _ = require('lodash')
const modulesConfig = require(`your module config js`)
const configurationName = process.env.MY_APP_CONFIGURATION ?? 'default'
const modules = modulesConfig[configurationName]
const template = fs.loadFileSync('name of template file')
const templateCompiled = _.template(template)
const generatedJS = templateCompiled({ `modules`: modules })
fs.writeFileSync('bootModules.js', generatedJS)
Write your template for bootModules.js. Simplest would be:
<% _.forEach(modules , function(module) { %>import '<%= module %>' as <%= module %><% }); %>;
import bootModules.js into your app
Use MY_APP_CONFIGURATION ENV variable to switch desired module configuration - works not just during development but you can also setup different CI processes targeting same repo with just different MY_APP_CONFIGURATION values
This way you have all configurations at one place, you don't need to change package.json before every build, you have simple mechanism to switch between different module configurations and every build (bundle) contains only the modules needed....
In an OOP world I would just use dependency injection retrieving classes implementing a specific interface, but in JS/TS I'm not sure it is viable.
Why not?
More than this, with JS/TS you are not restricted to use classes implementing a specific interface: you just need to define the interface (i.e. the module.exports) of your modules and respecting it in the libraries entries (vue build lib).
EDIT: reading comments probably I understood the request.
Each module should respect following interface (in the file which is the entry of the vue library)
export function isMyAppModule() {
return true;
}
export function myAppInit() {
return { /* what you need to export */ };
}
Than in your app:
require("./package.json").dependencies.forEach(name => {
const module = require(name);
if(! module.isMyAppModule || module.isMyAppModule() !== true) return;
const { /* the refs you need */ } = module.myAppInit();
// use your refs as you need
});

Different settings for debug/local ("grunt serve") vs. dist/build ("grunt")?

I want to define some application settings, but I want to provide different values depending on whether I'm running in 'debug' mode (e.g. grunt serve), or whether the final compiled app is running (e.g. the output of grunt). That is, something like:
angular.module('myApp').factory('AppSettings', function() {
if (DebugMode()) { // ??
return { apiPort: 12345 };
} else {
return { apiPort: 8008 };
}
});
How can I accomplish this?
The way I handle it in my apps:
move all your config data for one environment to a file: config.js, config.json,... whatever your app finds easy to read.
now modify your config file to turn it into a template using grunt config values, and generate the file with grunt-template as part of your build - for example: app.constant('myAppConfig', {bananaHammocks: <%= banana.hammocks %>});
finally, add grunt-stage to switch grunt config values depending on environment: create your different config/secret/(env).json files, update your template (app.constant('myAppConfig', {bananaHammocks: <%= stg.banana.hammocks %>});), and then grunt stage:local:build or grunt stage:prod:build
I find this the good balance between complexity and features (separation between environments, runtime code not concerned with building options,...)

Using Gulp to create angular $templateCache per module/directory

So, I'm moving from grunt to gulp (or trying to anyway), and I'm having trouble getting gulp to do what I'm doing in grunt. Specifically the $templateCache stuff.
My angular app is broken up into several components/modules. Each module contains everything it needs to run (controllers, directives, partials, scss, etc.).
Using Grunt, I've been able to boil each module down into 5 files:
module.min.css // all module scss files compiled and concatenated
module.min.js // all module controllers, directives, services, etc. concatenated
module.tpls.min.js // all partials in $templateCache for this module
module.mocks.min.js // all unit test mock objects for this module
module.specs.min.js // all unit test specs for this module
This has worked really well for 2 years now and been a cornerstone of my modular architecture. My only reasons to try out gulp was 1) Curiosity, 2) My grunt file is getting kinda hairy as we add in deployment and environment specific stuff and so far gulp has really slimmed that down.
For the most part, I've figured out how to do all my grunt tasks in gulp, but I'm having trouble figuring out how to generate a template cache file for each module. All the gulp-ng|angular-templates|templatecache plugins take all my partials and create one file. I'd like to take all my files under module/partials/*.html and create a single module.tpls.min.js; and do that for each module.
This was actually a problem with grunt too, but I figured it out with grunt.file.expand().forEach() like this:
grunt.registerTask('prepModules', '...', function(){
// loop through our modules directory and create subtasks
// for each module, modifying tasks that affect modules.
grunt.file.expand("src/js/modules/*").forEach(function (dir) {
// get the module name by looking at the directory we're in
var mName = dir.substr(dir.lastIndexOf('/') + 1);
// add ngtemplate subtasks for each module, turning
// all module partials into $templateCache objects
ngtemplates[mName] = {
module: mName,
src: dir + "/partials/**/*.html",
dest: 'dev/modules/' + mName + '/' + mName + '.tpls.min.js'
};
grunt.config.set('ngtemplates', ngtemplates);
});
});
My current gulp for this same task:
var compileTemplates = gulp.src('./src/js/modules/**/partials/*.html', {base:'.'})
.pipe(ngTemplates())
.pipe(gulp.dest('.'));
I've only really looked at the options, but none of them seemed to do what I wanted. They were all around changing the file name, or the final destination of the file, or a module name, or whatever else; nothing that said anything about doing it for only the directory it happens to be in.
I had thought about using gulp-rename because it worked well for me when doing the CSS compilation:
var compileScss = gulp.src('./src/js/modules/**/scss/*.scss', {base:'.'})
.pipe(sass({includePaths: ['./src/scss']}))
.pipe(rename(function(path){
path.dirname = path.dirname.replace(/scss/,'css');
}))
.pipe(gulp.dest('.'));
However, when I pipe rename() after doing ngTemplates() it only has the path of the final output file (one log entry). When you console.log() path after sass(), it has all the paths of all the files that it found (lots of log entries).
Any ideas? Thanks!
This SO post has the correct answer, but the wasn't coming up in my searches for this specific usage. I was going to vote to close my question, but since someone else might search using my own specific terms (since I did), it seems more appropriate to leave it alone and just redirect to the original question as well as show how I solved my own particular problem.
var fs = require('fs');
var ngTemplates = require('gulp-ng-templates');
var rename = require('gulp-rename');
var modulesDir = './src/js/modules/';
var getModules = function(dir){
return fs.readdirSync(dir)
.filter(function(file){
return fs.statSync(path.join(dir, file)).isDirectory();
});
};
gulp.task('default', function(){
var modules = getModules(modulesDir);
var moduleTasks = modules.map(function(folder){
// get all partials for this module
// parse into $templateCache file
// rename to be /dev/modules/_____/______.tpls.min.js
return gulp.src(modulesDir + folder + '/partials/*.html', {basedir:'.'})
.pipe(ngTemplates({module:folder}))
.pipe(rename(function(path){
path.dirname = './dev/apps/' + folder + '/';
path.basename = folder + '.tpls.min';
}))
.pipe(gulp.dest('.'));
});
});
It's essentially like the tasks per folder recipe but with a change to use gulp-ng-templates. I'll probably be using this same pattern for my SCSS and JS now that I'm more aware of it.
Seems like the gulp equivalent of grunt.file.expand().forEach().
Whenever I deal with scss/sass for gulp tasks, I will only put one scss file as the source parameter. This parameter file is composed of a list of imports. This way you don't need to rely on gulp to concat the scss file contents for you.
//in gulpfile
gulp.src('./src/js/modules/**/scss/main.scss', {base:'.'})
//in main.scss
#import 'a', 'b', 'c';
a, b, and c would represent your other scss files.

Gulp/Grunt: Concatenate only necessary JS files?

Wot I got
I have a gulpfile that produces app.min.js and libs.min.js; fairly selfexplanatory:
var dev = {
libs: [
'bower_components/angular/angular.min.js',
'bower_components/angular-foundation/mm-foundation-tpls.min.js',
'bower_components/underscore.string/dist/underscore.string.min.js'
]
};
var build = {
js: 'public/js'
};
gulp.task('libs', function() {
return gulp.src(dev.libs)
.pipe(concat('libs.min.js'))
.pipe(uglify({mangle: false}))
.pipe(gulp.dest(build.js));
});
In this setup, whenever I add or remove a library, I have to manually add it to the dev.libs array (and in the right order, too), then restart Gulp to see the new lib file.
Wot I WANT
I want to be able to concat the js libs I use without having to specifically define them in (array) dev.libs. At the moment if I use return gulp.src('**/*.js'), I believe it will concat every single js file in bower_components, which'd obviously be ridiculous.
Question
Is there a way to automatically load and concat the libraries I need, without having to define them in a gulpfile?
For Bower, you can use the plugin main-bower-files that will parse the content of your bower.json and search for the main file(s) of each of your dependency, so you don't have to declare each lib.
var bowerFiles = require('main-bower-files');
You can then do :
gulp.task('libs', function () {
return gulp.src(bowerFiles())
.pipe(concat('libs.min.js'))
.pipe(uglify({mangle: false}))
.pipe(gulp.dest(build.js));
});

rename templates folders with a gruntjs custom init task

I'm trying to create a custom init task for a personal template in Grunt.
This is the js which generate my new project after a grunt init:mytemplate
exports.description = 'Try Grunt';
exports.warnOn = '*';
exports.template = function(grunt, init, done) {
grunt.helper('prompt', {type: 'skin'}, [
grunt.helper('prompt_for', 'name', 'trygrunt'),
grunt.helper('prompt_for', 'title', 'Im Trying GruntJS'),
grunt.helper('prompt_for', 'author_name', 'Myself')
],
function(err, props) {
var files = init.filesToCopy(props);
init.copyAndProcess(files, props);
done();
});
};
Everything works fine: files and folder are correctly generated or renamed from the root folder of the custom template based on rename.json info.
The question is: how can i also dynamically rename folders and not only files?
i.e.
{
"libs/name.js": "libs/{%= name %}.js" //this works fine
"src/name": "src/{%= name %}" //this doesn't work
}
The init.filesToCopy method only looks at renames.json for specific file (not directory) matches when it first builds the files object. Your best bet is to programmatically modify the files object between init.filesToCopy and init.copyAndProcess.
This is possible by modifying the result of the init.filesToCopy object. However you need to modify the key rather than the value of each pair.
For example, I have a folder called lib/ that I wish to copy the contents into app/
var files = init.filesToCopy(props),
libFolder = 'app';
// Repath the files correctly
for (var file in files) {
if (file.indexOf('lib/') > -1) {
var path = files[file],
newFile = file.replace('lib/', libFolder + '/');
files[newFile] = path;
delete files[file];
}
}
init.copyAndProcess(files, props);
It's also worth noting that rename.json works on the lib/ value not the new folder.
One thing that I've done is to use the props.main value to extract the libFolder value (e.g. libFolder = props.main.split('/')[0])
Another way to accomplish this and get around the limitation of not being able to rename folders, is to 1) setup a grunt-contrib-copy task to copy the folders and files and apply whatever names you require to the new folders/files, and then 2) have a grunt-contrib-clean task clean out the old files/folders resulting in the same net effect as renaming the folders.

Categories

Resources