Skip to content
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

Merged
merged 7 commits into from Sep 28, 2017
Merged

Add hjson support #30

merged 7 commits into from Sep 28, 2017

Conversation

ghost
Copy link

@ghost ghost commented Sep 28, 2017

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

@codecov
Copy link

codecov bot commented Sep 28, 2017

Codecov Report

Merging #30 into master will increase coverage by 0.54%.
The diff coverage is 100%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
readers/hjson.js 100% <100%> (ø)
config.js 89.74% <100%> (+0.7%) ⬆️
configfile.js 70.24% <100%> (+0.14%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ce7243a...a584727. Read the comment docs.

@ghost ghost mentioned this pull request Sep 28, 2017
@KingNoosh KingNoosh requested review from msimerson and a team and removed request for msimerson September 28, 2017 13:02
@ghost
Copy link
Author

ghost commented Sep 28, 2017

The Codecov is now messed up as I accidentally pushed to the same branch. The accident is removed but the Codecov stayed.
Sorry...

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') {
Copy link
Member

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?

Copy link
Author

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';
}
Copy link
Member

@msimerson msimerson Sep 28, 2017

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);
         }

Copy link
Author

@ghost ghost Sep 28, 2017

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

Copy link
Member

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.)

Copy link
Author

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?

Copy link
Member

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' }
Copy link
Member

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, understood

@msimerson
Copy link
Member

Whoohoo, looks great except that you've also added a package-lock.json, which is likely something that npm just did "for you." Maybe we should add that to .npmignore for now?

@ghost
Copy link
Author

ghost commented Sep 28, 2017

Yes, definitely it should be in .gitignore or something.

@msimerson
Copy link
Member

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/*.

@msimerson msimerson self-requested a review September 28, 2017 21:52
@ghost
Copy link
Author

ghost commented Sep 28, 2017

Ok, should I include it in this PR or should I create a new one?

@msimerson
Copy link
Member

Either way is fine.

readers/hjson.js Outdated
const Hjson = require('hjson');

exports.load = function (name) {
return Hjson.parse(fs.readFileSync(name, "utf8"));
Copy link
Member

@msimerson msimerson Sep 28, 2017

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.

Copy link
Author

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.

Copy link
Member

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.)

Copy link
Author

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.

@msimerson
Copy link
Member

fixes haraka/Haraka#2124

@msimerson msimerson merged commit e82a402 into haraka:master Sep 28, 2017
@msimerson
Copy link
Member

thanks @PSSGCSim

@baudehlo
Copy link
Contributor

baudehlo commented Sep 28, 2017 via email

@ghost
Copy link
Author

ghost commented Sep 29, 2017

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.

@baudehlo
Copy link
Contributor

baudehlo commented Sep 29, 2017 via email

@ghost
Copy link
Author

ghost commented Sep 29, 2017

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.

@baudehlo
Copy link
Contributor

baudehlo commented Sep 29, 2017 via email

@msimerson
Copy link
Member

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.

@baudehlo
Copy link
Contributor

baudehlo commented Sep 29, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants