New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access to current config in profile config? #399

Closed
kbaltrinic opened this Issue Jun 27, 2014 · 7 comments

Comments

Projects
None yet
2 participants
@kbaltrinic

kbaltrinic commented Jun 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@dbashford

dbashford Jun 27, 2014

Owner

If your config is javascript, then something like

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

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

Owner

dbashford commented Jun 27, 2014

If your config is javascript, then something like

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

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

@kbaltrinic

This comment has been minimized.

Show comment
Hide comment
@kbaltrinic

kbaltrinic Jun 27, 2014

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 commented Jun 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kbaltrinic

kbaltrinic Sep 19, 2014

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.

kbaltrinic commented Sep 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@dbashford

dbashford Sep 19, 2014

Owner

Hrm.

is your project set up like this? ish?

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

dbashford commented Sep 19, 2014

Hrm.

is your project set up like this? ish?

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

This comment has been minimized.

Show comment
Hide comment
@kbaltrinic

kbaltrinic Sep 19, 2014

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

kbaltrinic commented Sep 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@dbashford

dbashford Sep 19, 2014

Owner

👍

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

Owner

dbashford commented Sep 19, 2014

👍

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

This comment has been minimized.

Show comment
Hide comment
@kbaltrinic

kbaltrinic Sep 19, 2014

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.

kbaltrinic commented Sep 19, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment