-
Notifications
You must be signed in to change notification settings - Fork 255
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
Support using nconf in a (browserify-based) browser context #130
Comments
+1 |
This module has some potential, but it doesn't work on the current source of NConf because of the 'lazy-loading' of the files: https://github.com/substack/brfs |
+1 |
OP here. @toddpi314 @naoufal, I ended up using mozilla's convict module, which I bent to my browser needs through a little intermediate layer using superagent. See discussion in mozilla/node-convict#47 , which lead to a solution now documented in their README.md and probably applicable to nconf too:
@indexzero @jcrugzz if you deem this solution applicable and acceptable in nconf, feel free to close. |
Thanks @ronjouch. I'll give that a shot and report back. |
Not sure I follow: is it lazy-loading or lazy-loading the directory? In other words, does d501e7b fix it? |
@indexzero It fixed it for me, FWIW. I'm using browserify. |
When I use d501e7b I get a different error
|
Hi, |
d501e7b fixes things for me as well. Using webpack. |
As mentioned above, d501e7b fixes the issue by removing the usage of |
Still getting error after compiling with browserify
|
also webpack builds for a nodejs context fails with "Error: ENOENT: no such file or directory, scandir '//nconf/stores'" due to the lazy loading pattern based on fs. |
Hi.
Like StackOverflow post "using nconf in the browser", I'm trying to use your package in a browserify setup, but because nconf calls
fs.readdirSync
when it isrequire()
d to scan directories for configuration, it fails in the browser.→ Is it something that sounds feasible with nconf, or do you suggest going for another package / custom solution?
Thanks for the help, and sorry for posting this as an issue, it's more of a question to which "we do not and will not support that" can be a fine answer.
The text was updated successfully, but these errors were encountered: