Feat: Expose program config (when used on cli) #927
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
My proposal is to expose a config property together with the db property on the express application created by json-server cli with the content of the configuration parsed by yargs, useful in particular when using the
-c, --config
flag since yargs will set all properties as arguments, this allow plugins to have their namespace of options in the config file without any other changes and it will open many customization possibilities to plugins and third party modules based on json-server.For example take this json-server plugin which right now expose middlewares (to hook into json-server cli) with this update the user can define for example a auth property in the configuration file:
And this configuration can be later accessed, for example in the
/login
route exposed by the middleware, like so:This will resolve many of the issues the plugin is facing right now, which depends basically on the possibility to pass custom configurations.
Pros
The third point is about having this middleware features to be capable of handling the basic needs otherwise implemented by the modules which requires the author of the plugin to depend on a (per package) version of json-server instead of simply hook up to the user choice version as middleware.
Cons
Any consequence? I'm open to feedbacks.
My english is not very good and I've helped myself with g.translator, so if something is not clear about what I tried to explain, please tell me 😄