You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[ ] Regression
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.
Current behavior
Currently, it's only possible to instantiate the module via the .withConfig method. It is not possible to inject a service into this method, so it is impossible to use a config service for the module instantiation.
Expected behavior
Enable both the .withConfig method and a factory-pattern method, that allows dependency injection.
What is the motivation / use case for changing the behavior?
I don't want to use process.env variables as all my config logic is inside a config module. It is possible to override this behavior by manually injecting all config values into process.env, but this seems like a bad choice.
Environment
Nest version: 6.6.0
For Tooling issues:
- Node version: 12
- Platform: Windows
Others:
The text was updated successfully, but these errors were encountered:
I'm submitting a...
Current behavior
Currently, it's only possible to instantiate the module via the .withConfig method. It is not possible to inject a service into this method, so it is impossible to use a config service for the module instantiation.
Expected behavior
Enable both the .withConfig method and a factory-pattern method, that allows dependency injection.
What is the motivation / use case for changing the behavior?
I don't want to use process.env variables as all my config logic is inside a config module. It is possible to override this behavior by manually injecting all config values into process.env, but this seems like a bad choice.
Environment
The text was updated successfully, but these errors were encountered: