Access to current config in profile config?

[kbaltrinic]

Is there a way to access the current configuration when declaring a profile configuration (say by require()ing it in)? This would be very useful. The most obvious case is the need to add modules to the existing list of mimosa modules. Its a maintenance issue when one has a list of modules in the default mimosa configuration and then needs to add web-package to a deployment profile for example. As it is now, if I add a new module to my default config, I need to remember to go and add it to all of my profile configurations as well.

It would be nice to be able to grab the existing modules array, push additions to it and then just return that array. Quick example code:

defaultConfig = require('mimosa-config');
exports.config = { modules: defaultConfig.modules.concat(['module1', 'module2']); }

[dbashford]

If your config is javascript, then something like

baseConfig = require('../mimosa-config').config

should work. Not somewhere I can play with that though.

[kbaltrinic]

Cool, I'll check that out. I am guessing I should take care not to actually modify the base config, maybe do a deep clone of it first just to be safe?

[kbaltrinic]

So I finally got around to a point where I needed this again. You were close. The correct solution is:

baseConfig = require('../../mimosa-config').config

Can you maybe work this into the documentation for profiles somewhere? Then we can close this issue out.

[dbashford]

Hrm.

is your project set up like this? ish?

mimosa-config.js
/profiles
    profileA.js
    profileB.js

[kbaltrinic]

Ah good catch... I have both my profiles and my adhoc modules in subfolders under a common parent like

mimosa.config.coffee
/deploy
  /profiles
  /modules

[dbashford]

:+1:

K, so, can use, just its relative is all.

Curious, what are you using adhocs for? Anything broadly applicable?

We turned our biggest adhoc into this: https://github.com/peluja1012/mimosa-defeature

[kbaltrinic]

Not that I can think of. One manually patches some of our bower dependencies introducing some customization using regexes to do the trick. It does this on the fly at compile time This way (so far) we are free to upgrade the dependencies w/o having to manually fix each new version. Another reconfigures the app for production if a production build. A third on the drawing board will mangle some of our code to make it work in EI8, again at compile time, so that we remain free to keep writing our code in a saner, non-IE-compatible way. That might sound generally useful but its not. If we go there its going to have a very narrow focus on some known angular incompatibilities.