Shared state causes side effects across modules about dynamic-config HOT 6 CLOSED

Fix shipped as breaking change with 1.0.0

from dynamic-config.

Thanks @benurb for pointing out. The npm change has a lot of side effects nobody was thinking about in the first place :)

If var dynamicConfig = require("dynamic-config").createInstance(); works without breaking changes, then it's the way to go imho. Do you propose returning an instance (for backwards compatibility) with a createInstance() method to solve the current hazzle?

from dynamic-config.

Yes, it's basically a factory pattern.
Nevertheless I would prefer the breaking change. I cannot imagine a case where the current behavior is desired. It's totally unpredictable, because it depends on loading order. But of course the factory method would solve the problem, too. What's your opinion?

from dynamic-config.

I'm always surprised that the shift from npm2 to npm3 works so well for most projects, because imho many modules suffer from this issue.

In this particular case, I'm a little bit surprised that you have two modules which depend on dynamic-config. Shouldn't dynamic-config be a typical module that is only required by the actual application? Why is your dependency using dynamic-config?

Besides that I agree with @benurb. This should be a breaking change. Existing applications should be very easy to upgrade.

from dynamic-config.

Actually already npm2 is an issue here, because it dedupes after install.

My specific use case is that we have a project, which runs integration tests on our backend infrastructure. Therefore it lists all the services as dependencies and each of these services uses dynamic-config. Pre-npm2 each service would have a node_modules/serviceX/node_modules/dynamic-config module, but since npm2 they all share the same instance in node_modules/dynamic-config, because the "outer" module also has a dynamic-config dependency.

from dynamic-config.

In your particular case, the argv and env plugin don't really make sense because they assume a 1:1 relationship between dynamic-config instance and process (or otherwise equally named config keys will clash).

So imho in your situation it's more suitable to spin up multiple processes as it reflects the actual use-case better.

Your proposed change, however, is still reasonable because you might want to use dynamic-config for multiple configs. In this case, however, still the argv and env plugin don't really make sense.

from dynamic-config.