[BUG] TypeError: Cannot redefine property when sub module is using config.get() within the module about node-config HOT 7 OPEN

We've also had that problem since version 3.3.8 came out. My colleague and I have been working on it for two days and the only real way we've found to solve it is to fix the version to 3.3.7.

The problem seems to be this merge: #516. If I go into the config.js in node_modules and revert the change by hand, it works fine.

from node-config.

👋🏼 Any thoughts on the issue above?

from node-config.

@lorenwest @markstos was this intentional? If so, what's the proposed direction when handling modules?

from node-config.

@hershmire The regression was not intentional. I've asked @fgheorghe who wrote the patch #516 to investigate. Ideally we'd like that fix without regressions, but maybe we can't have both and have to choose.

from node-config.

@markstos you sure about that?

If you unroll their code they are running:

config.util.setModuleDefaults('myModule', defaults);
const apple = config.get('myModule.apple');

config.util.setModuleDefaults('myModule', defaults);
const apple = config.get('myModule.apple');

Which I'm pretty sure the docs imply you should not do.

My read on setModuleDefaults is that you should not be calling it when running a function in your module, you should be running it when the module loads. That way repeated calls do not trigger this problem.

from node-config.

I just ran into this problem when resolving two different versions of a package in my dependency tree. The package tries to call config.util.setModuleDefaults('myModule', defaults); in both versions, at module load.

How can a package ensure it has defaults set in an idempotent way?

I realize that its somewhat dangerous for two different versions of a library to be setting default values, because the defaults might change between versions, causing default values from the past or future of the package to be seen, but in the case where the defaults are the same, maybe it could be made to be a no-op instead of breaking?

from node-config.

@NilSet It seems like each sub-module should have a private configuration. The best way to do this may be with breaking changes. It was addressed in this fork, which should perhaps be published as it's own module.

#569

from node-config.