Divide Config.js into modules

artieikon

I also agree with this approach as it will allow us to script configuration/deployment easier. It would be similar to configurations done in other applications ie Nginx. For loadbalancing you just have a folder you can add all endpoints, ports, what have you and the system itself will read everything in there and make a master behind the scenes.

I’ve tried to do something similar and stitch them together by hand but it seems that if i place any ‘require’ statement in the config.js file MM does not properly load my configs. I can monitor the logs and everything gets parsed and output properly, just when i go to the actual UI it just shows the standard “Please create a config file.” screen. I could not find any logs anywhere that show any additional errors of why this is not wanting to start.

sdetweil

@artieikon require is not allowed in module.js, but you could use the getScripts function to load them

Also

Start mm in developers mode

npm start dev

Then select the console tab to see what’s going on in the modules
Node_helpers display info in the terminal window

A Former User

I always want Conditional Loading or Lazy Loading. I want programmable Pre-processor for which module should be loaded or not by just mention it.
And if configuration for each module be separated, PPL would make less mistakes on configuration step and at least, It could be easier to find which configuration wrong.

ejay-ibm

I can only agree 1 config file per module in the config folder and you can get rid of a lot of mistake

sdetweil

@sean thats all cool, but will take significant rewrite of the core services…

artieikon

@sdetweil said in Divide Config.js into modules:

@artieikon require is not allowed in module.js, but you could use the getScripts function to load them

Also

Start mm in developers mode
npm start dev
Then select the console tab to see what’s going on in the modules
Node_helpers display info in the terminal window

You are amazing! thank you so much for this

artieikon

@Sean
Lazy loading is always a quality thing to have. Anything that takes away from startup times and pre-processing generally helps user experience greatly.

I think it’s been overlooked because of the “hide modules using an orchestrater” so its not like functionality is being lost. But the benefit of it would still be there

sdetweil

@artieikon also, please create a config file is because of a syntax error in the config file…

from the MM folder do

npm config:check

fix errors from the top down

sdetweil

@artieikon yeh, but generally people startup once and it runs for months…

artieikon

@sdetweil

npm run config:check

but that actually came back valid since there are no syntax errors it just blew up on me runtime. The dev mode properly shows what is the issue though