-
Notifications
You must be signed in to change notification settings - Fork 13
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
Add hjson support #30
Conversation
Codecov Report
@@ Coverage Diff @@
## master #30 +/- ##
==========================================
+ Coverage 80.73% 81.27% +0.54%
==========================================
Files 7 8 +1
Lines 410 422 +12
Branches 118 123 +5
==========================================
+ Hits 331 343 +12
Misses 79 79
Continue to review full report at Codecov.
|
The Codecov is now messed up as I accidentally pushed to the same branch. The accident is removed but the Codecov stayed. |
config.js
Outdated
@@ -54,7 +54,7 @@ Config.prototype.getDir = function (name, opts, done) { | |||
}; | |||
|
|||
function merge_config (defaults, overrides, type) { | |||
if (type === 'ini' || type === 'json' || type === 'yaml') { | |||
if (type === 'ini' || type === 'hjson' || type === 'json' || type === 'yaml') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
after a few conditionals, it gets cleaner to convert this to a switch/case. Agree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, will do
configfile.js
Outdated
} | ||
|
||
name = yaml_name; | ||
type = 'yaml'; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This entire section doesn't seem right. The gist of this section is to let a .yaml file override a missing json file. You want to extend it to let a yaml override a hjson or json file. The easiest way to fix it is to revert this section back and then make this alteration:
--- a/configfile.js
+++ b/configfile.js
@@ -338,11 +338,11 @@ cfreader.load_config = function (name, type, options) {
if (!fs.existsSync(name)) {
- if (!/\.json$/.test(name)) {
+ if (!/\.h?json$/.test(name)) {
return cfrType.empty(options, type);
}
- const yaml_name = name.replace(/\.json$/, '.yaml');
+ const yaml_name = name.replace(/\.h?json$/, '.yaml');
if (!fs.existsSync(yaml_name)) {
return cfrType.empty(options, type);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made it so HJSON can be overridden by JSON and also YAML, but I might be wrong
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hrmm, I'm wondering how useful that is. Using YAML in place of JSON? Easy to see the use case. Using HJSON instead of JSON, against easy to see. Using JSON in place of HJSON? Why not just specify JSON? What's the point? (If there is a good point, it should be added in the docs.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I get it. So, should I change it to allow both to be overridden by YAML? Am I right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. Basically treat hjson the same as json.
test/config.js
Outdated
const hjsonRes = { | ||
matt: 'waz here', | ||
array: [ 'has an element' ], | ||
objecty: { 'has a property': 'with a value' } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The contents of this test file should be different than the contents of the json file, so that we're assuring that the correct file got read and parsed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, understood
Whoohoo, looks great except that you've also added a |
Yes, definitely it should be in |
Do feel free to add it. I think it's NPM 5+ that drops that file by default, so we'll likely be adding that to .gitignore in all the repos in haraka/*. |
Ok, should I include it in this PR or should I create a new one? |
Either way is fine. |
readers/hjson.js
Outdated
const Hjson = require('hjson'); | ||
|
||
exports.load = function (name) { | ||
return Hjson.parse(fs.readFileSync(name, "utf8")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, just noticed this: per the JS conventions, the case for the variable names of libraries is always lower case, except for constructors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was going to use it first, but then I went with what hjson's npm description gives as example. Shall be fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See: https://stackoverflow.com/questions/1564398/javascript-method-naming-lowercase-vs-uppercase (we deviate from the conventions slightly with the use of under_score names instead of camelCase, but we're pretty consistent otherwise.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I will remember that.
fixes haraka/Haraka#2124 |
thanks @PSSGCSim |
https://stackoverflow.com/questions/44206782/do-i-commit-the-package-lock-json-file-created-by-npm-5
This link seems to suggest we should keep the package-lock file.
… On Sep 28, 2017, at 6:04 PM, Matt Simerson ***@***.***> wrote:
thanks @PSSGCSim
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub, or mute the thread.
|
If you read it, I do not think this file is all that needed. Because |
I’m no fan of npm 5. It caused me tons of headache and lost time at work. I just wanted to show what the general consensus was.
… On Sep 28, 2017, at 8:50 PM, Jan Schwarzrock ***@***.***> wrote:
If you read it, I do not think this file is all that needed. Because npm creates it itself while running npm install and it only stores integrities and such regarding the installation (the sub-modules). If we would need to do so I think package.json should be sufficient. I think this would be important only if you would like to host configuration of an instance on git. Like for updating and fetching exactly same modules at each deployment.
Correct me if I am wrong.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I have linked the npm's docs onto this issue in the |
Totally not needed. It’s a question of does it benefit or not. I don’t have an opinion either way.
… On Sep 28, 2017, at 9:02 PM, Jan Schwarzrock ***@***.***> wrote:
I have linked the npm's docs onto this issue in the .gitignore. e82a402#diff-a084b794bc0759e7a6b77810e01874f2
I am not all that experienced with Node.js/npm but from what I got it is not needed.
Again, please correct me if I am wrong.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub, or mute the thread.
|
While acknowledging that the consensus appears to be: check it in, my opinion is that if we do decide to, we should wait until after we drop support for node 6 (and with it, npm 3). For now, I'm personally avoiding npm 5 for a while longer, thanks to show-stopper bugs. Shucks, NPM 5 is what finally convinced me to give yarn a try. For now, I'm sticking with npm 3 for a while longer, while npm 5 gets most of the pathological bugs ironed out. |
I agree with you Matt. I've had the same problems. npm5 was a clusterfuck
for us.
…On Fri, Sep 29, 2017 at 1:50 PM, Matt Simerson ***@***.***> wrote:
While acknowledging that the consensus appears to be: check it in, my
opinion is that if we do decide to, we should wait until after we drop
support for node 6 (and with it, npm 3). For now, I'm personally avoiding
npm 5 for a while longer, thanks to show-stopper bugs. Shucks, NPM 5 is
what finally convinced me to give yarn a try. For now, I'm sticking with
npm 3 for a while longer, while npm 5 gets most of the pathological bugs
ironed out.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#30 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAobY8kbuRUeoM6MhT463pJOa0AF9C4Vks5snS3TgaJpZM4PnH6B>
.
|
Adding HJSON support, does not support json override
Started in haraka/Haraka#2124
P.S.: All test work but someone should really check what I wrote, but I assume you do it anyways