mathew-kurian / mathew-kurian/node-configify
Repeating yourself?
- Dominant language
- JavaScript
- Stars
- 5
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Description
I understand why you would limit the configuration available client side, so that you don't expose server internals, file-structures, encryption tokens and what not,
BUT: With the method of only giving access to what is under the "Client" key, don't you end up having to repeat a lot of stuff under "Client:", making the config files more complex and potentially error prone?
The stuff that get's repeated is typically (for me) URLs to API:s, variations in behavior depending on target, et c.
Or am I missing something crucial here, making it a nonissue?
To be a little more constructive, I think a good solution might be to apply a specific client-target-config file in the stack of configs, where you could specify and "un-specify" various parameters, rather than having a specifc parameter in the tree.
(Also, I dislike the fact that the signifier of what is safe to send to clients is hardcoded as "Client". In my case specifically, the fact that the first letter is capitalized breaks form with all my other keys which were already standardized in snake_case ... but that's a separate issue and only a minor gripe)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the node-configify Browserify transform and how it currently exposes values under the "Client" key. The issue proposes client-target configuration files and a configurable client-safe marker, but provides no acceptance criteria, files, tests, or settled design; done would need to be defined first.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100